A string of question about Locking & Isolation Level

Question

Hi All
It is highly appreciated if someone give offer answers to my below questions
1) There are two ways of locking mechanism: Pessimistic & Optimistic. In general, do all J2EE app server support all these two ways of locking ?
2) It seems to me that setting the isolation level to "serialization" should result in using pessmistic locking. If no so, please point out my misconcept and explain to me.
3) Are there any differences in the way of entity bean programming as different locking mechansim is adopted ?
4) With regard to optimistic locking, will the app server throw out exception as data contention is detected ? Is the way of handling dependent on app server? Or It is transparent to the developer of entity bean. Please give me an e.g of j2ee app server product how to handle this scenario.
5) To adopt the approach of "optimistic" locking, do l have to implement it on my own using bean managed entity bean.
6) It seems to me that optimistic locking can achieve better concurrency. If it is inherently supported by app server for its container managed entity bean (=> totally transparent to the developer of entity bean). Is it always the rule of thumb to config the server to use "optimistic" locking instead of "pessimistic" ?
Sorry for bombarding you guys with such long list of questions. l would be very thankful if someone can help me consolidate my concept on these topics.
Also, please send your reply to [email protected] as well
thanks & regards
Danny

Answer 1

Hi Danny,
I became interested about the optimistic locking recently. If the topic is not long forgotten then this may make some difference!
We have attacked the optimistic locking issue by introducing audit fields (MODIFY_BY_USER, MODIFY_DATE) in tables where concurrency needs to be implemented.
We are retrieving rows from the table (for display or update) through Stateless Session Bean using simple SQL SELECT. The audit fields are fetched along with the business data and are kept at the client. While any of the concurrent users tries to update the row the audit fields are sent to the application server along with the modified business data. The relevant Entity Bean checks for any difference in the timestamp of the audit field (MODIFY_DATE) value with the value in the database. If a mismatch is found it reports a business exception to the user. Otherwise, the row is updated with the lastest timestamp value in the audit field MODIFY_DATE.
This works fine when two update operations are not concurrent, i.e., two users submit their update requests in a time lag greater than the time taken by the transaction to complete. This alone could not prevent the dirty update on the database.
Hence, to prevent any concurrent update contending for the same row you need to set the following ejbgen tag in the Entity Bean:
concurrency-strategy = Exclusive<<<<<Note: We are using Weblogic 6.1 with SP4 and CMP (no BMP).
Please let me know if you have got a better solution to tackle this issue.
Chandra.