A new website www.precisejava.com has been launched with a full repository of over 100 best practices to improve performance in J2EE and J2SE applications. The site includes EJB, JDBC, Servlets, JSP, JMS and Patterns.

Look at www.PreciseJava.com.

Feel free to give your feedback here.

There is a lot of good content here! One thing that is lacking is more J2EE patterns, such as the ones in my book (http://www.theserverside.com/resources/patterns_review.jsp) and the ones in TheServerSide.com's pattern repository.

Floyd

Yes and see this one :
http://gotdotnet.com/team/compare/default.aspx

the ultimate performance...

Let's please not start this up again about the .Net vs J2EE decision and the incredibly unfair comparison of the two Pet Store implementations.

Take that thread back to the topic where it was discussed. This one is about J2EE best practices.

Floyd,
I agree with you. This site is not covered all the design patterns because it is totally concentrated on how to improve performance in J2EE using patterns rather than putting all the patterns but i also agree that this can have few other performance improvement patterns as well.

I should say..
A EJB designer or developer must read EJBPatterns book that is available online in this site(theserverside.com)..

http://www.precisejava.com gives a unique collection for J2EE performance improvement.

Regards,
Ravi.

I am not able to find the site... can you please cofirm if the url is right?
Thanks

URL is fine and working...
Try again and the URL is
http://www.precisejava.com

Ravi.

Still can not access that site. Please check it.

Can't access it too
bye
-stephan

Can't access site:
http://www.precisejava.com/

This site is designed and tested for above Netscape4.0 version and IE4.0 browsers because of bugs in Netscape4.0 version and usage of DHTML in this site. You can not access this site if you use Netscape4.0 and may not be able to access if you use lower versions of IE browsers. So if you use NS4.0 or below version, Please upgrade and try, it should work. There must be some Service Pack available if you want to use Netscape4.0 and don't want to upgrade to fix the bugs.
It is best to upgrade to the latest versions for both browsers.
The problem is because of DHML usage in this site that needs latest browsers.

For Netscape upgrade, visit
http://home.netscape.com/download/index.html
For IE upgrade, visit
http://www.microsoft.com/windows/ie/downloads/default.asp

We will give an error message to the site users in the future to resolve this issue.

Thank you,
Best Regards,
Ravi.

Site Dead? www.precisejava.com

No...Site is alive...
:-)

Please upgrade your browser as I told above in one of the reply thread. See above replied thread for detailed information.

www.precisejava.com needs latest browsers in order to handle DHTML.

Thank you,
Ravi.

Ravi,

I am not (never have) used NS 4.0. I am using IE6.0 and Mozzarella 0.95. The home page took about 60 seconds in IE and about 3 in Mozzarella.

Are you any relation to Precise (the performance tools company)?

Peace,

Cameron.

I should blame ISP where i hosted precisejava.com for that figure.
But i can say it is happening that this site takes that much time very few times.
Other than that it should be fine as per my observation since one month.

Thanks,
Ravi.

My client can't connect to your server, so my
browser can't be the reason for my problems.

(either routing problems, DNS problems or
your server is down)

bye
-stephan

I think it must be problem with DNS propagation.
It looks like DNS propagation is not finished properly in very few DNS servers.
and also it should be problem with very few DNS servers only because I am getting mails from all over the world and hits are coming from almost 65 countries.
Can you tell me from where you are accessing this site? So that I can resolve the problem easily.

Thank you,
Ravi.

Hi Ravi,
   Not able access your site???
    I tried "ping www.PreciseJava.com its working but
not able to view using IE browser 5.50.I am accessing from Trivandrum,India.

Prash

This site is excellent....
Lot of good content..

Vivek.

Hi Prash,
Thanks for your comment that you could not access www.precisejava.com.
I spoke to my ISP provider and ISPs need to refresh/update DNS information periodically. If they don't refresh/update frequently, it takes some time to access this site till your ISP refreshes/updates.
Hopefully the problem is resolved soon.
This problem is not specific to anybody or any one country since this site is receiving hits from almost 65 countries at present.
Thanks,
Ravi.
webmaster at precisejava dot com

In the J2SE performance section on loops ( http://www.precisejava.com/javaperf/j2se/Loops.htm ), this page contains a bug in the code that "proves" one should always compare the terminating condition of a loop with zero.

for(int i=a.length-1;i==0;i--){
  a[250000]+=i;
}

Of course this code finishes in 0ms: it doesn't do anything!

This may be pedantic but..

(example code from site)
if(home == null) {
    ctx = getInitialContext();

If you want to improve performance, the first thing that you want to cache is the InitialContext. In the example code the initial context is created each time a new home is looked up.

It does depend on the appserver, but obtaining the initial context is a substantial cost for a remote ejb client - sometimes taking over 1 second.

Nick,
The reason I did not cache InitialContext is because practically it amounts to very less as a performance issue when compared to caching Home stubs. For example if an application has 50 EJBs, then there will be only 50 calls to the InitialContext when compared to plenty of calls to the Home stubs, we can say 5% to 95% (this is only an example, it varies and can reduce the number of calls to the InitialContext). But I agree that we can even improve performance a little bit by caching InitialContext.

If you observe this code carefully, one important performance consideration is synchronizing getHome() method. By using synchronized keyword, it is restricting concurrent clients to access that method that is a performance issue. There are few solutions for this problem

1.Implementing double checked locking, this failed in java in previous JVMs although it is a good approach.
See, http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Present JVMs may solve this problem that needs to be checked.

2.Initializing the object at instance level, this is a good approach.
3.Synchronizing the method as shown in the code. This does not result in better performance when compared to above approaches if you use previous JVMs But HotSpot JVM really works well even though methods are synchronized. This approach can be followed depending upon concurrent accesses.

As a whole, for me, initializing object at the instance level is better approach and even synchronizing a method is safest if an application uses HotSpot JVM and has limited concurrent accesses.

So, I implemented one of the above solutions.
Our approach is to make the EJB developers aware of caching the EJB Home stubs in simple manner, but they can cache them however they want because some developers may have better approaches than the above mentioned.
Thanks for raising this important issue.

Best Regards,
Ravi.

Hi Lucas,
Thanks for your comment.
I think software + No Bugs...
That is my dream..
But you are correct and the bug is fixed.
Ravi.

Hi
saw your website www.precisejava.com,
it has a lot of excellent stuff..
great work !!! keep it up...
:-)
-Naren

The page contains the following recommendation:
> Avoid using try-catch inside the loops instead place the > loops inside the try-catch for better performance

Is that really true? I don't think that making a call
into a try/catch block has any performance drawbacks.

I just wrote a small test to compare, and the program
has the same run time, whether or not the try/catch block
is inside the loop or outside.

Hey Andrej,

In case of a heavily executed piece of code, which might have do deal database operations or some file I/O operations, placing try/catch blocks inside loops can slow down code execution.

If "try/catch" blocks are inside loops, code execution can be about 21 percent slower if the JIT compiler is turned off on a JVM without a JIT.

Hence it is recommended not to put try/catch blocks within loops. If you want more information check out book Practical Java - Programming Language Guide by Peter Haggar or Java Performance Tuning by Jack Shirazi.

Krishna

There is a book entitled 'Practical Java' by Peter Haggar which covers various programming techniques, showing good and bad practices including amon others try/catch blocks.

I have found this a very good reference book.

Thanks
Lee Miles
Mobile Entertainment Applications www.theimode.com

Hi,

Can anyone help me clarify few things about Entity Bean? Let's say I have 100 clients simultaneously accessing one Entity Bean and all of them are accessing the SAME record from a database (A). If I maintain over 100 instances in instance pool, does each client gets its own instance?

Question #2, how many database accesses (to A) it would be? According to EJB spec., it would be 100, is that right?

Question #3, what if I have to get big chuck of data from another database (B) based on an ID from the record of the current database (A)(represented by Entity bean instance), does this data loading happen once or 100 times? Again, according to EJB spec., it would be 100 times, right?

Maybe Entity bean isn't fitting this problem at all.

any comments/advices would be highly appreciated

Fox

Hi Fox,
If we assume that a entity bean maps to the single row in the database .Then i guess there will be only one instance of the entity bean for all the clients.The thread safety is taken care by the container.
The Weblogic application server does it this way .

Fox,
These answers are as per my understanding for your questions.

Answer for Question1:
Yes...If the instance pool size is 100 then each client gets an instance.
Here, when that each client gets the instance data is also an important point. It depends upon Isolation level that inturn depends up on read/write/other database specific locks.
Suppose if you set an isolation level that controls write lock but not read lock, then clients get faster instance data because clients need not wait to complete previous client transaction. I assumed here that each client accesses with separate transaction.

Answer for Question2:
For this question, It is little bit tough to give one answer because it depends on EJB caching, transaction and application server specific properties.
But with general EJB properties I can say, EJB container has to access 100 times because whenever a new client access the request for an EntityBean instance EJB container has to make sure that it gets the latest data by synchronizing the database.
But with other properties, for example if you make EntityBean as read-only bean by setting read-only caching property, then it does not have to access database 100 times rather it accesses only once and all other clients get the cached data.

Answer for Question3:
If that ID of database-A is FK in the database-B, then it does not load the entity beans of type-A.
If you access initially type-A EJB for getting ID and then access type-B, then it loads all the type-A beans with full data and loads type-B beans.
The best way here is to design custom EntityBeans with BeanManaged Persistence that does not represent the database table rather it has the fields that maps to the two database tables and having join queries.

Finally,
Important considerations for EntityBeans are
1. Database connection pool size and it's properties
2. EntityBean pool and cache size and it's properties
3. Transaction commit control
4. Isolation level control
5. Lazy loading
6. Application server specific properties etc…

For detailed information visit www.PreciseJava.com.

I hope this helps.
Ravi Kalidindi.
webmaster at precisejava dot com

thanks you all for your comments/advices

FX

A lot of it looks very good, but unfortunately there's also some bad advice to be found.

The explanation of Content-Length in the JSP section is confusing (or inaccurate) and can lead to problems. Unless you're abusing JSP as a glorified servlet it's usually impossible to predict the content length anyway.

The bit about collections recommends Vector all over the place. I agree with Sun that Vector, Stack and Hashtable are obsolete and should not be used outside legacy software. Their performance in practice is often worse than that of their Collections counterparts. The retrofit into the Collections framework has made their API bloated and confusing. They don't sit easily in the framework anyway. In the very, very rare case that you need your collection synchronized, use Collections.synchronizedList(List) and friends.

The recommendations about thread safety are way off the mark. "if you are not sure that whether your collection needs to be thread safe or not then better to use Vector to have higher safety". When I encounter such defensive programming in code it strikes me as a sign of incompetence. Anyone taking this "safe" approach is guaranteed to produce thread-unsafe code; the comfort factor offered by a synchronized collection will lure you into thinking the code is threadsafe. If you are not sure whether your collection needs to be threadsafe or not, keep your fingers off the keyboard and consult a colleague more comfortable with threads.

In the Object Creation section, it says "Use lazy evaluation, lazy object creation whenever possible". Such blanket advice is dangerous unless properly qualified - it can make your application more complicated for zero or even negative performance gain.

To a slightly lesser extent this is actually true for a lot of the advice given; performance optimisation usually makes code harder to write, debug and maintain. Much of it should be applied only after profiling has shown a performance bottleneck (which all too often is not where you expect it).

 - Peter

I should really add that overall, hats off for the site. A very useful piece of work and I'm looking forward to following how it develops.

 - Peter