... or an EJB container at all?
- Posted by: mitch chapman
- Posted on: August 17 2005 20:38 EDT
I have inherited a web application made up of a Tomcat servlet container, an EJB container, and an Oracle database.
The servlets use RMI to call methods in the EJBs. The EJBs use a pool of database connections to connect to the database.
The problem is that all the data passed back to the tomcat container must be serialized (deconstructed and reconstructed). This can add (relatively) a lot of time to a large transaction.
My question is - would I be better off simply connecting to the database directly from the Tomcat container using a connection pool? That would avoid having to serialize/stream the java objects back and forth between the Tomcat container and the EJB container.
This brings up the issue of how the EJB container handles pooling of the EJBs themselves. In my app, the EJBs are all SessionBeans, and they do not maintain any persistent state or data. They simply provide a gateway to call the stored procs in the db. They also get reused.
If I wanted to transfer the role/functionality of the EJBs to my Tomcat container, would I need to employ some type of object pooling for these classes, which only serve as the gateway to the DB? Or could I simply rewrite these EJBs as new classes with static methods?
Basically, I am wondering about the performance difference between reusing my EJB-like classes (via some pool in the Tomcat container), versus calling static methods in some class to accomplish the same functionality.
If multiple threads are calling the same static method simultaneously, or different static methods of the same (non-instantiated) class, does the JVM have to "load up" multiple copies of the class and or method? If so, how are these cleaned up? Basically I want to compare this scenario (calling many static methods simultaneously from different threads) against some type of reusable object pool, which would hopefully not require constant loading and cleanup.
if your session beans don't implement any business logic at all and, as you say, are only used to execute sql statements and stored procedures then you probably don't need them, it's total overkill.
On the other side, serialization and de-serialization shouldn't add a noticeable amount of time to your method execution, unless you really transfer huge - and I mean HUGE - amounts of data from your ejbs to your webapp, but why would you do that?
In this kind of layered architecture the webapp is supposed to be the presentation layer, data transferred to it is generally supposed to be displayed to the user. but displaying a HUGE amount of data to the user in just one page is never a good idea. Since you already have EJBs, you should use them to filter data retrieved from the database and only return to your webapp data that is going to be shown to the user and data that you need to build further requests.
In any case, if you keep the EJBs, avoid doing anything else then presentation logic in your webapp. Any business logic and data processing / filtering should in this case be implemented in the EJBs.
If you keep the EJBs and you still want to avoid serialization, you can try to put local interfaces on top of your session beans and deploy your webapp on the same application server as your beans. Most containers allow you to do that.
Emil Kirschner ( http://testare.dev.java.net )
Thanks for the advice.
The reason for some of the large amounts of data is to generate reports which the user can save to their PC.
Some of the reports can cover a lot of data.
If I do decide to scrap the EJB container and just connect directly to the DB from the servlet container, is there any problem with converting my current EJB methods into static methods of some class? Or is there a benefit to using some kind of object pooling, where the pooled objects are "like" my old session beans in that they can be reused by multiple threads?
I just haven't found any good discussion about the performance aspects of calling static methods which connect to the db and call stored procs.
If I do decide to scrap the EJB container and just connect directly to the DB from the servlet container, is there any problem with converting my current EJB methods into static methods of some class?.
It shouldn't be. Be careful about transaction demarcation, though. If your beans are configured in CMT mode, remember to start a user transaction in your servlet each time the container would start one for you now.
If your db operations are read-only - you say you generate reports, that sounds like read-only - then there is no need to start transactions. This could more or less improve performance.
The only other thing that can influence performance is the container's db connection and thread pooling mechanism. Make sure your connection pool is properly sized for the number of simultaneous connections you expect for your webapp.
Emil Kirschner ( http://www.thekirschners.com )