The way I understand it, we would only have one transaction associated with a thread.

In pseudo-code form, the lock code would be something like:

public void lock( Object resource, short mode ) throws ...
{
    Transaction tx = _threadLocalTx.get();

    synchronized ( _locks ) {
        Lock lock = _locks.get( resource );
        if ( lock.owner.equals( tx ) ) {
            // already owner
            // upgrade lock if necessary
           return;
         }
    }
}

So there would be no need to pass around the transaction object, and no risk of having two transactions associated with a thread, or two threads associated with a transaction if we correctly protect the entrypoints (begin, suspend, resume, commit).

alex


Kevin Day wrote:
Bryan-
 
If I have 2 transactions that all attempt to grab a lock on the same resource, the following is a very likely scenario:
 
Both transactions are running in the same thread - in this case, synchronization constructs would not block at all (synchronization is re-entrant), and the transactions would be allowed to proceed, even though serialization may be violated.
 
That's why I'm thinking that the transaction has to be part of the lock request - I think the blocking operation needs to be done in the context of a thread/transaction pair - not just per thread.  But maybe I'm misunderstanding your implementation's behavior.
 
I'll let Alex address the point of wanting to be able to hand a transaction from one thread to another, but I could definitely see where something to that effect would be necessary if workflow process queues are being used.
 
- K