Ok.  It definitely simplifies both the 2PL API and the implementation.




From: Alex Boisvert [mailto:boisvert@intalio.com]
Sent: Monday, March 27, 2006 10:40 AM
To: Thompson, Bryan B.
Cc: Kevin Day; JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking.


Having spent a fair amount of time implementing OLTP system, I do support the "one transaction, one thread" design. Every design make tradeoffs and this one has proved to be a sweet spot in terms of balancing complexity and performance (e.g. maximizing throughput).


Thompson, Bryan B. wrote:
> I am wondering about the

relationship between transactions, threads,

> and locking for 2PL. If the API assumes that the thread is the

> context in which the locks apply, then the lock object (which

> contains some metadata about the lock) can be hidden (for the most

> part) from the application and the method for releasing a lock can

> simply use the current thread to determine which lock should be

> released. A lock which is not granted immediately causes the thread

> in which the lock request was made to block. This makes all kinds


> good sense and is how the java.concurrent.util APIs are laid out.


> However this assumes that the notion of a transaction is equivalent

> to a thread, that there can not be more than one transaction per

> thread, and that the transaction can be inferred from the thread.

> This also suggests that a transaction factory is basically a thread

> pool (which gives us a means to limit concurrency) and that


> of a transaction requires setting the Runnable target on a thread


> some application code that embodies the transaction.


> Thoughts?