> 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
