'Kevin Day ' wrote:
>> Just to be clear, the design that I proposed did not allow the possibility
>> one thread running more than one transaction.
Right - that's why I'm proposing a subtle change to the approch where locks are transaction based and not thread based.
I'm also in favor of this.
 Alex - In the following discussion, notice that we are having to do a lot of asserts in the transaction methods - this is one of the reasons that I was thinking we should just pass the transaction into the calls on the lock manager...  If we do that, it gets rid of the setCurrentThreadTransaction and releaseCurrentThreadTransaction completely, and keeps the context of the locks straight...  I guess I'm still not entirely convinced that using the thread local variable is a good thing here...
The most compelling reason for me to set the transaction in thread-local storage is to avoid tainting APIs with transaction parameters all over.

It happens quite frequently that you have to use other APIs, say java.lang.Runnable, that passing transaction objects around becomes a nuisance.   In those cases, you end up either passing transaction objects in member variables or managing your own thread local.

Based on discussions I've seen on the concurrency-interest mailing list, I'm not too worried about performance of thread-locals.  If you have to somehow management the thread-transaction affinity, I'd rather have the framework handle this in a bulletproof manner.