3.2

Derek Hulley

Take a transactionally-managed lock. This method can be called repeatedly to both initially acquire the lock as well as to maintain the lock. This method should be called repeatedly during the transaction to ensure that the lock remains refreshed. DO NOT use a long-lived lock to avoid calling this method at intervals; long-lived locks get left behind during server crashes, amongst other things.

The following rules apply to taking and releasing locks:
- Expired locks can be taken by any process
- Lock expiration does not prevent a lock from being refreshed or released
- Only locks that were manipulated using another token will cause failure

The locks are automatically released when the transaction is terminated.

Any failure to acquire the lock (after retries), refresh the lock or subsequently release the owned locks will invalidate the transaction and cause rollback.

Take a transactionally-managed lock. This method can be called repeatedly to both initially acquire the lock as well as to maintain the lock. This method should be called repeatedly during the transaction to ensure that the lock remains refreshed. DO NOT use a long-lived lock to avoid calling this method at intervals; long-lived locks get left behind during server crashes, amongst other things.

The following rules apply to taking and releasing locks:
- Expired locks can be taken by any process
- Lock expiration does not prevent a lock from being refreshed or released
- Only locks that were manipulated using another token will cause failure

The locks are automatically released when the transaction is terminated.

Any failure to acquire the lock (after retries), refresh the lock or subsequently release the owned locks will invalidate the transaction and cause rollback.

If the lock cannot be immediately acquired, the process will wait and retry. Note that second and subsequent attempts to get the lock during a transaction cannot make use of retrying; the lock is actually being refreshed and will therefore never become valid if it doesn't refresh directly.

Take a manually-managed lock. The lock current thread or transaction will not be tagged - the returned lock token must be used for further management of the lock.

No lock management is provided: the lock must be released manually or will only become available by expiry. No deadlock management is provided, either.

Take a manually-managed lock. The lock current thread or transaction will not be tagged - the returned lock token must be used for further management of the lock.

No lock management is provided: the lock must be released manually or will only become available by expiry. No deadlock management is provided, either.

If the lock cannot be immediately acquired, the process will wait and retry.

Take a manually-managed lock and provide a callback to refresh it periodically. A convenience wrapper around getLock(QName,long) and refreshLock(String,QName,long,JobLockRefreshCallback).

Refresh the lock using a valid lock token.

Provide a callback to refresh a lock using a valid lock token, pushing responsibility for regular lock refreshing onto the service implementation code. This method should only be called once for a given lock token to prevent unnecessary refreshing.

Since the lock is not actually refreshed by this method, there will be no LockAcquisitionException.

The TTL (time to live) will be divided by two and the result used to trigger a timer thread to initiate the callback. The first refresh will occur after TTL/2 and no significant work should be done between acquiring a lock and calling this method, to prevent expiration.

Release the lock using a valid lock token.

Release the lock using a valid lock token. The lock can have been taken by another process (i.e. the lock token will no longer be valid); none of this will prevent the method from succeeding.