jboss use pessimistic or optimistic locking mechanism


EJB programming & troubleshooting: jboss use pessimistic or optimistic locking mechanism

  1. Dear All

    As far as l know, there are two different approaches to transactional locking: Pessimistic locking
    and optimistic locking. How can l configure the jboss to use either one of above locking mechanism ? l think all j2ee app servers should support "pessimistic" by setting the isolation level to "serialization". But l don't know whether most of server support the "optimistic" or l need to implement this mechnism by the use of bean managed container entity bean. It is highly appreciated somebody can detailedly explain to me

    Please send your reply to cwso7 at netscape dot net as well

  2. Hi,

    the JBoss server configuration - to use either Pessimistic or Optimistic locking - can be set up via container-configuration in the specific Jboss deployment descriptor jboss.xml. You can have a look to standardjboss.xml in your conf directory for default configuration.
    You'll find in this descriptor a <locking-policy> element, allowing you to specify the class implementing locking policy. The default for CMP is set to org.jboss.ejb.plugins.lock.QueuedPessimisticEJBLock which implements pessimistic policy (you can choose either org.jboss.ejb.plugins.lock.MethodOnlyEJBLock). I think you should be able to implement your own locking policy by subclassing one of this class and redefining schedule() method.

    I hope it'll help you ...

  3. Hi Laurent

    l am grateful to your fast response and helpful answer to my question. One more question, if l want to to optimistic locking, what is the class name l have to use for the tag of "<locking>". In addition, it seems that optimistic locking offer much better concurrency, is it the rule of thumb always to use "optimistic" locking ? Also, if the "optimistic" locking is used and jboss find out there is contention between record in db and the corresponding entity bean, how does jboss deal with it (e.g throwing exception ?, if so, what is the class name of the exception). Finally, any distinction in the ejb programming for different locking configuration.
    Sorry for throwing out so many questions at once and thanks anyone for answering these question in advance.

    thanks a ton !
  4. I think (somebody will tell me if I'm wrong ...) that the Optimistic policy is only available from version 3.0.0 and I don't know (for the moment) the name of the pluggable implementation.
    However, there's an alternative solution to the "raw" pessimistic default policy of JBoss 2.4.x, making your transactions run as "READ_COMMITTED" (useful when you have a lot of read-only beans). Just use the following container configuration elements :
    <interceptor>org.jboss.ejb.plugins.EntityLockInterceptor</interceptor> <interceptor>org.jboss.ejb.plugins.EntityMultiInstanceInterceptor</interceptor> <interceptor>org.jboss.ejb.plugins.EntityMultiInstanceSynchronizationInterceptor</interceptor>

    This creates one active Entity instance per transaction instead of one Entity Instance per container.
    The disadvantage is that the commit-option of your configuration must be 'B' or 'C' (for synchronisation at the beginning of every transaction). The Jboss web site provides a set of of slides dealing with this subject but unfortunately, the page is unavailable for the moment ...

  5. Hi all / Laurent

    But is there any distinction in the ejb programming for different locking configuration? With regard to "optimisitc" locking, do l need to trap any exception caused by data contention or it is simply transparent to the developer of entity bean ? If there is data contention, how can l handle it. Just throw back it as application exception, rollback the transaction and then notify the user to retry the operation.
    In addition, is this option available in other j2ee app server ? If so, how do those servers deal with the questions l raised above.

    It is highly appreciated someone can clear up my above queries.

    thanks you very much in advance