Kevin Day wrote:
Interesting.  Does this imply that there can only be one executing Tx per thread at any given point in time?  I think this starts to break down, though, because you can't release the locks when you suspend a Tx (not without viloating 2PL, anyway).
I don't understand.  Can you provide an example of what you mean?
No matter what Bryan does, he still has to deal with the fact that a single thread could wind up needing to block itself (by definition, this would be deadlock).  This scenario is pretty easy to detect, and should probably abort one of the transactions (it implies that the application developer has not designed their threading/transaction handling properly).
In the scheme I was proposing, a transaction holds locks, not a thread.   If a transaction holds a lock, it cannot block itself.  You can only get into a deadlock situation with two or more transactions.

(If you want locks for synchronizing threads, you can use java.util.concurrency or something alike)