EJB programming & troubleshooting: Feasibility of using Optimistic Locking managing

  1. Hi all,
    I am using versioning for optimistic locking pattern as described in ejb design pattern. all by business operations takes DTOs and does bulk operation. Now, I am keeping a version cmp field in my dtos and programatically increasing it for each update operation. If I find a version mismatch I am throwing exception manually. I am not using any Container specific facility because I want to keep my design container independent.

    Now, I would like to know your view on this approach. I am new to ejb and want to know how much feasible it is. And how would it relate with my container's Commit options & isolation levels?

    If I am using jboss & mysql, What should be my minimum isolation level for this approach to work? What should be my commit option?
    How do I get an isolation level which is "Read_Commited with optimistic lock" as described in ejbDesignPatterns??

    any comment will be greately appriciated.
  2. Sajid,
       I would assume that before update u extract the actual version value from db and compare it with that of DTO . U can safely use the isolation level READ_UNCOMMITTED which is the most efficient but allow all dirty,repeatable and phantom reads.Considering the fact that programatically any change in the fields of the bean is tracked it is safe to do so except a very rare case where both commit happen at almost the same instance of time. i.e. the getUpdatedVersion call in update happens before or during the commit call is completed by another client . Hence a commit call after that would allow dirty commit .A possible solution in this case could be using READ_COMMITTED .But this would be a very rare case and u need to take a decision between making it a little bit more efficient verses making it more robust. Hope this helps.

  3. Thnx Debashish.
       Suppose I use Read_Commited. Than, what happens when say at a rare instance, Two clients read the exact same data at the exact same time & passed checkAndUpdateVersion(). say the version was 10 before and they both made it 11. What will happen when both of them tries to commit their transaction? In this senario, I want either one of them pass and other fail.
     How do I achieve that. In the book, ejbDesignPattern, this senario is told but the sulution is not clear.
     What do you think?

  4. This case is definatley a caveat . A possible solution could be putting the call to updateVersion() in synchronized block . But it is highly discouraged in EJB environment as u never know the behaviour of the container .It could be multiple instances for multiple clients for the same row in which case it would not work or it could be same instance for same row for multiple clients in which case it would work . But except this case be assured that for Read_committed any update in db in the scope of the transaction is synchronized. Honestly I dont find any other solution. May be if you find let me know.