Hi All

It is highly appreciated if someone can provide 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 cwso7 at netscape dot net as well

thanks & regards
Danny

1) There are two ways of locking mechanism: Pessimistic & Optimistic. In general, do all J2EE app server support all these two ways of locking ?

A) I assume you mean their CMP implementations. No this is not specified by the spec and containers do take different approaches.

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.

A) That would be the 'safest' way to do so.

3) Are there any differences in the way of entity bean programming as different locking mechansim is adopted ?

A) No you shouldnt care. Either strategy must maintain the ACID state of the tx so it shouldnt matter from your point of view. Especially in CMP since you dont deal with the persistance at all anyway.

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.

A) Its normally transparent, although some containers do some interesting things to deal with this. Sybase EAS used to throw a specific runtime exception which the SB's could catch and retry. Normally the persistance layer should do something to signal callers they need to 'redo' the work again as the optimistic lock was violated.

5) To adopt the approach of "optimistic" locking, do l have to implement it on my own using bean managed entity bean.

A) If your CMP persistance layer doesnt provide it yes. But honestly any worth its salt should

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" ?

A) Optmistic locking can provide for better concurrency yes. The biggest issue with OL is that it is often buggy so make sure you buy a good persistance layer. Also it often requires multiple retries in a high concurrency environment which doesnt necessarily mean better performance then traditional locking. Nothing guarantees the ACID state of the tx better and safer then pessimistic locking.

Dave Wolf
dave at getpersonified dot com