Agreed.   Conceptually speaking, I can see transaction semantics is layered on top of the 2PL services. In practice I have found good reasons to have minor inter-dependencies, namely to offer better debugging/tracing facilities.  Remember the law of leaky abstractions ;)


Thompson, Bryan B. wrote:



This also implies that the concept of a “transaction” lies mostly outside of the scope of the 2PL package.  2PL gets defined solely in terms of coordinating concurrent access to resources for purposes of consistency while the rest of the transactional semantics (e.g., durability, atomicity, etc). have to be handled elsewhere.


Which sounds fine to me.




From: [] On Behalf Of Thompson, Bryan B.
Sent: Monday, March 27, 2006 10:51 AM
To: Alex Boisvert
Cc: Kevin Day; JDBM Developer listserv
Subject: RE: [Jdbm-developer] 2PL: transactions, threads and locking.


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




From: Alex Boisvert []
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?