Hi Tim, In general, detection of the OptimisticLockException condition won't happen until commit time. The expected isolation level for JPA is RC (Read Committed). So, until a commit action completes and makes the changes "public", the check for an optimistic lock exception can't happen. Or, maybe I should say "shouldn't happen"... :-)
Your testing with Derby is a little confusing. With Versioned entities, OpenJPA produces the same type of SQL for updating a Versioned entity. We have to increment the current Version column (X+1), given the current value of the Version is X. When this SQL gets flushed to the database, we are relying on the database to tell us whether that SQL will be accepted or not. Maybe this can be detected at flush time, but more likely it won't be detected until commit time. The JPA spec is pretty wide open on this issue. All that it really states is that the optimistic lock condition must be detected at some point. The idea is to request the locks as late as possible to avoid serialization of operations. And, just so that the provider doesn't allow the overwriting of data and throws the OptimisticLockException sometime before a commit() completes for this condition, then the provider is okay. Related to all of this is that I am assuming that all of your experimentation did eventually end up with an OptimisticLockException. And, besides Derby, what other databases are you experimenting with? Thanks, Kevin On Fri, Feb 20, 2009 at 12:41 AM, Tim McConnell <[email protected]>wrote: > Hi, I'm a little confused about the OpenJPA optimistic locking behavior > relative to the flush() and commit() methods. For example, if I modify an > entity (which contains a version) in one transaction, do an em1.flush(), and > modify the same entity in another transaction, and do another em2.flush(), I > would expect to see an OptimisticLockException on the second flush. This > does in fact happen like this on the Derby database, but not on any other > databases I've tried. So, I'm wondering if I should instead expect the > OptimisticLockException only when the transaction(s) end via the commit(), > and not on the flush() ?? > > -- > Thanks, > Tim McConnell >
