Re: [Jdbm-developer] 2PL: transactions, threads and locking.

[Alex B. <boi...@in...>]

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 ;)

alex


Thompson, Bryan B. wrote:

> Alex,
>
> =20
>
> 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.
>
> =20
>
> Which sounds fine to me.
>
> =20
>
> -bryan
>
> =20
>
> =
------------------------------------------------------------------------
>
> *From:* jdb...@li...
> [mailto:jdb...@li...] *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.
>
> =20
>
> Ok.  It definitely simplifies both the 2PL API and the implementation.
>
> =20
>
> -bryan
>
> =20
>
> =
------------------------------------------------------------------------
>
> *From:* Alex Boisvert [mailto:boi...@in...]
> *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.
>
> =20
>
>
> 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).
>
> alex
>
> 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
>
> of
>
>> 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
>
> execution
>
>> of a transaction requires setting the Runnable target on a thread
>
> to
>
>> some application code that embodies the transaction.
>
>>
>
>> Thoughts?
>
> =20
>