Alex,

 

Yes, this is more or less how I have been approaching things.

 

There are some differences.  The lock method is on the Queue class.  The Queue constructor accepts the resource, so a Queue is associated with a specific resource.  The locking model allows concurrent access to the resource as long as the lock mode is compatible, e.g., shared access by multiple readers.  But these have to do mainly with the specifics of the locking model.

 

What is the intention for _threadLocalTx.get()?  Is this an indirection to lookup the Transaction object associated with the current Thread as opposed to defining Transaction extends Thread?  If so, how would you suggest managing (or declaring) the association between a Transaction object and a Thread?

 

-bryan

 


From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Alex Boisvert
Sent: Monday, March 27, 2006 6:45 PM
To: Kevin Day
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking (rese nd!)

 

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