Hi Kyle, Since EJB specificaiton is standard one and the J2EE servers which support the J2EE has to abide by the specification, do we need to consider the container when designing for Record Lock feature in the application which we are building..? Let us say if we use Websphere or Weblogic, what has to be done if we want to implement row level record locking in the application ? If record lock depends on the container then doesn't it contradict the idea of J2EE certified App servers ? Thanks for the time.
Record locking depends on isolation levels and this is not covered by the EJB Specification (see Section 17.3.2). Most Application Servers do definitely address this, however they do it in a vendor-specific way. If record lock depends on the container then doesn't it contradict the idea of J2EE certified App servers? Not really. Record locking depends highly on things outside of the EJB Container's control such as the capabilities of the target database. Therefore, it would be impossible to require adherence to an absolute behavior without crippling performance (all locking would have to be handled in the EJB Container instead of delegating to the database). Besides, the point of the specification is not binary portability. It is to make portability between J2EE Servers possible without significant rewriting of the application. I think it is achieved in this regard.
I am most familiar with WebLogic so I will use that as my example... To control record-locking in WebLogic you must set the isolation level on your EJB in a vendor-specific descriptor. In the weblogic-ejb-jar.xml there is an element called transaction-isolation which contains an element called isolation-level with the following possible values: TransactionSerializable | TransactionReadCommitted | TransactionReadUncommitted | TransactionRepeatableRead | TransactionReadCommittedForUpdate | TransactionReadCommittedForUpdateNoWait. It is important to note that not all databases support every isolation level... so you once again need to spend a bit of time investigating which ones are available for your particular database. If you have questions on how to set isolation levels for a particular J2EE Server then I suggest you post the question to the specific forum for that Server. In general, setting isolation levels is a pretty simple task that can have huge consequences on the performance and behavior of your application so be careful.
Hi, I went through the link for Isolation Level in BEA site. Well it just helps us to define the degree to which a transaction exposes updated but uncommitted data to other transactions. If you consider the requirement I have which is locking a record so that no other user is allowed to update the same. If the other user tries to update the record he should get notification that someone else has already obtained the lock. This can be achieved through simple Java Bean which holds lock status for the records. Is this possible by using just Entity bean where I query for the record using "Select * from <mytable> where <criteria> for Update Nowait". Or do I need to use some combination of Session and Entity bean to achieve this? Hope I made the requirements clear. Cheers.
If you consider the requirement I have which is locking a record so that no other user is allowed to update the same. If the other user tries to update the record he should get notification that someone else has already obtained the lock. This can be achieved through simple Java Bean which holds lock status for the records. We are both talking about the same thing. The above example discusses how to enforce concurrency on a transactional basis... which is often what we want. To this on a per-bean basis you would need to use the use-select-for-update in the weblogic-cmp-jar.xml descriptor for your CMP Bean.