The semantics imposed by the API signature: lock( mode )


Is that the thread of the caller is blocked.  This is basically the same semantics that the java.util.concurrent.Lock interface is using except that the latter does not have a lock mode.  When the lock can not be granted immediately the current thread waits.  When the lock can be granted, the thread is notified.


There is no constraint against reuse of a thread for executing different transactions at different times, but the same thread must be used through the life of any given transaction.  If the responsibility for executing a given transaction is handled by t1 at one moment and t2 at another moment, then all of the synchronization logic would break.




From: [] On Behalf Of Alex Boisvert
Sent: Monday, March 27, 2006 2:46 PM
To: Kevin Day
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] 2PL: transactions, threads and locking.



You're raising a good point here and I realize I should have been clearer in my feedback.

What I meant is that I favor a design where only one thread can be associated with a given transaction at a time.  From experience, supporting multiple threads working in the same transaction is quite complex and is more expensive due to extra synchronization costs.

This design would support non-blocking/asynchronous IO's provided that you respect the thread-transaction contract.

To be clear, the limitation I would impose is to prevent multiple threads from operating in a transaction simultaneously.  At any point in time, a transaction would have zero or only one active thread.

Side note:  The argument for having multiple threads per transaction usually revolves around expensive computations.  I have found that in most cases, you can decouple the computations from the transaction-aware data structures to perform these computations in parallel threads and use synchronization to keep the transaction-handling logic in a single thread.


Kevin Day wrote:



Any comments in light of non-blocking IO for a highly concurrent server application that uses jdbm as a back-end?


It seems to me that locking and blocking are really separate concerns...  Certainly, there are many situations where they co-exist and overlap completely, but in the world of high-throughput, I'm not so sure that holds...


Just thinking out loud...


- K



> 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 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.


------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! _______________________________________________ Jdbm-developer mailing list