Ok. It definitely simplifies both the 2PL API and the implementation.
From: Alex Boisvert [mailto:email@example.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
> 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
> 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