Assuming that we can rely on JPA2, can the issues that Marvin pointed out, be addressed? Otherwise we should mark the JIRA issue as Won't Implement and document what Marvin has pointed out.
Cheers, Scott On Wed, Dec 22, 2010 at 9:55 AM, Marvin Addison <[email protected]>wrote: > > Because of that, i'm trying to replace the JDBC-based implementations to > > JPA. The first step was to implement a class that replaces > > JdbcLockingStrategy called JpaLockingStrategy. > > While a JPA implementation is very desirable since it can be made to > generate the required schema and simplify deployment, it has some > limitations (at least 1.0) that make some requirements difficult if > not impossible to implement. In particular, the acquire() method must > ensure that the following 2 operations are atomic: > > 1. lock availability check > 2. lock acquisition > > If the above requirement is not met, the following undesirable > sequence may occur: > > 1. Node A checks for lock and finds it available > 2. Node B checks for lock and finds it available > 3. Node A acquires lock and executes > 4. Node B acquires lock and executes > 5. Node A releases lock (which it doesn't actually hold according to > database state) > 6. Node B releases lock > > By my reading you have not addressed this requirement in your > implementation, and I believe it's not possible with JPA 1.0. (The > optimistic locking features in JPA 2.0 may provide a solution for at > least some platforms.) > > The JDBC implementation, on the other hand, uses SELECT FOR UPDATE to > acquire read-exclusive locks preventing step 2 in the bad case above; > it uses the SERIALIZABLE transaction isolation level on SQL Server > which doesn't support SELECT FOR UPDATE. Locking semantics vary > dramatically among database platforms, and platform-specific > strategies are likely the only reliable solution for a database-backed > lock implementation. > > M > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
