In our project we need to do lot of transactions. Each transaction does lot of operations with database. The operation includes select,update,insert and delete. We are planning to write only session beans to do these transactions. There may be lot of concurrent updation to the same data also can happen in our system. In such situation, Will the update statements written in my session beans as the part of transaction create any problem? Is it necessary to do that updates alone through an EntityBean? If I am not using EntityBean in such cases, will it lead to database deadlock problems?
Please clarify me.
please refer one wonderful book on ejb by Ed Roman. This was a free download on this site sometime back.
Ed Roman argues that entity beans are a must for transactions.
please reply me what u think about this to krishavg at yahoo dot co dot in
I'd say no, but qualify it by adding that it depends on your circumstances.
In a project that I am currently working on, we initially set everything up using entity EJB's, with stateless session EJB's 'wrapping' them to form the transactions.
However, because of the existing database design, most of the transactions hit one particular row on a particular table. Even though this was generally a read (although a process running outstide Weblogic could update it, so it wasn't read-only), we hit major problems with Weblogic's pessimistic locking.
Eventually, we've moved everything over to Stateless EJB's which mirror the Entity EJB functionality.
The database locking problems have now gone away, and the system runs as quick, if not quicker, than with entity EJBs.
I'd say that if you're designing your database from scratch, then Entity EJB's are the way to go. But, I can't see a problem using JDBC from session EJB's if you require it (as we did).
As an aside, using JDBC & Entity EJB's in the same system should be OK, but we did experience problems, which is why we moved onto purely Stateless EJBs.
I would say it depends on what you are doing.
Personally, I don't like entity beans, particularly in WebLogic due to it's pessimistic locking, as already discussed here.
If your system hits a small number of rows, steer well clear of entity beans. Use session beans (preferable stateless) and JDBC. If you do that, you should try to write some classes that encompass the SQL statments (table and column names etc.) so that you don't have to change 30 files if you change a column name. :-)
If your system hits a large amount of data in a well dispersed pattern (Use the same reasoning you would use to decide what columns to put a clustered indexe on) then you are probably OK with entity beans.
In either case you have to take care to set the transaction isolation levels and the transaction requirements correctly to avoid corrupt data so that isn't so much of a factor.
Entity beans might be important if your server doesn't have exclusive control of the database, since they refresh their contents before running methods, which a session bean won't do unless you code it that way.
It's horses for courses really, you need to examine the distribution of load across your system and knock up some simple test harnesses to give you an indication.
Thank you all.
I decided to use only stateless session beans and JDBC to do the transactions. Not going to use EntityBean at all, even though the data can be accessed concurrently by many clients. By setting the proper isolation level, I think, we can avoid the Oracle dead lock problem.
One confusion still, Could you please tell me in single word whether we need enitybean in transactions or not?
Thanks a lot.