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.
thanks & regards
Will do my best...
1) Most of them probably do, but don't take my word for it. If you really need pessimistic locking and the App server doesn't support it, you can implement it on BMP yourself (or change the CMP's generated SQLs) by turning the SELECT statements into "SELECT ... FOR UPDATE".
2) Not neccesarily. It depends on the database server you use. Oracle, for instance, applies an optimistic approach with version numbers. If two transactions begin and read the same row, they do not block each other. The first transaction to commit goes through. When the next one tries to commit, it fails with a "cannot serialize transaction" error. Look at your DB's docs for specific info.
3) What do you mean "locking mechanisms"? Do you mean concurrency control algorithms (pessimistic, optimistic, etc)? If so, then generally not, unless specific locking-related code is hard-coded into the bean. Such a case is using a "SELECT ... FOR UPDATE" statement to achieve a reader-blocks-reader effect on DBs such as Oracle.
4) The App server must not allow the transaction to commit. The transaction will be rolled back, and an exception will be thrown to the user. The specific exception is not important, and a portable EJB client must not depend on the specific type of exception thrown.
5)That depends on what you mean by "optimistic locking". For instance, many databases will implement optimistic locking for the transactions running on the database. So in that case, you don't need to worry about it. What you might mean is to implement "long-term transaction", where a "transaction" spans more than a single DB transaction. This is common, for example, when you give the user a set of data to update, and you don't know how long it will take for the user to commit the changes. In that case, you may not want to force the DB to retain all the transaction information for such long periods of time. So you can implement optimistic locking yoursef (see the Patterns section for some info). Note that such implementations are *extremely* prone to errors by users who are not found in the low-level details of the EJB spec, so you better try and read through the threads describing these patterns: the initial descriptions often contain errors.
6) Not neccesarily. Optimistic locking requires an additional level of version information, and an additional call for comparing that information (when implemented by the container rather than the DB). If you generally do not expect a lot of concurrent calls, pessimistic locking may perform better.
Hi Gal / All
Your answers is great help to clear up my concept. Thanks you very much for your help. with regard to your answer, l still have a question.
As mentioned in answer 4 & 5, if optimistic locking is adopted and data contention is detected by server, exception(probably, it is system exception, correct ?) will be thrown out by server. l am aware that a portable EJB client should not rely on server specific exception. Howwever, if my client code do not examine the type of exception thrown out, how come can my client know the exception is due to data contention instead of other exceptions such as network error. Nor can my client program request the user to retry the operation ?
It is highly appreciated Gal / anyone can further elaborate on it
thanks a lot in advance