I was just looking at ACID on Wikipedia.  2PL would support isolation rather than consistency.


·        Consistency refers to the database being in a legal state when the transaction begins and when it ends. This means that a transaction can't break the rules, or integrity constraints, of the database. If an integrity constraint states that all accounts must have a positive balance, then any transaction violating this rule will be aborted.

·        Isolation refers to the ability of the application to make operations in a transaction appear isolated from all other operations. This means that no operation outside the transaction can ever see the data in an intermediate state; a bank manager can see the transferred funds on one account or the other, but never on both—even if she ran her query while the transfer was still being processed. More formally, isolation means the transaction history (or schedule) is serializable. For performance reasons, this ability is the most often relaxed constraint. See the isolation article for more details.




[1] http://en.wikipedia.org/wiki/ACID


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




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: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] 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 [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?