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

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).


Kevin Day wrote:
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