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