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.
[mailto:email@example.com] 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...
> 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.
------------------------------------------------------- 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! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Jdbm-developer mailing list Jdbmfirstname.lastname@example.org https://lists.sourceforge.net/lists/listinfo/jdbm-developer