A type upgrade can queue and potentially time out, causing a JoobObjectLockedException to be thrown, if the requested type is not compatible with existing locks. For example, this could happen when upgrading a shared lock to exclusive.
Lock type downgrades will never be queued, as the strength is being lowered so there will be no lock incompatibilities.
When a JADE session is in transaction state, requests to downgrade lock type are ignored. The lock maintains its current type. However, lock types can be upgraded regardless of transaction state.
When a lock type is being upgraded from shared to update, the object is unlocked before the update lock is requested. This happens even if the JADE session is in transaction state, and is the only situation where an object is unlocked while in transaction state. The reason for doing this is to prevent potential deadlocks, as discussed in more detail under “Avoiding Deadlock Exceptions”, later in this chapter.
The following code fragment gives examples of upgrading and downgrading lock types.
TimeSpan timeOut = TimeSpan.FromSeconds(10);
context.Lock(obj1, LockType.Shared, LockDuration.Transaction, timeOut);
context.Lock(obj1, LockType.Reserve, LockDuration.Transaction, timeOut);
// The lock is now upgraded from shared to reserve.
context.Lock(coll, LockType.Exclusive, LockDuration.Transaction, timeOut);
using (System.Data.IDbTransaction tran = context.BeginTransaction())
{
context.Lock(obj1, LockType.Exclusive, LockDuration.Transaction,
timeOut); // The lock type is upgraded to exclusive, as
// locks can be upgraded (but not downgraded)
// when in transaction state.
foreach (C1 obj2 in coll)
{
// The exclusive lock on coll is not downgraded by the implicit shared
// lock associated with foreach, because transaction state is in effect.
}
context.Lock(obj1, LockType.Shared, LockDuration.Transaction, timeOut);
// The lock type is not downgraded, but remains as exclusive.
tran.Commit(); // All transaction duration locks are released.
}