Let me try to summarize.  There are two reasons why start/suspend/resume might be required: non-blocking single threaded IO and passing responsibility for executing a transaction down a chain of thread pools associated with a staged processing model.  The other use case that I find interesting is parallel processing.  

 

The staged processing use case makes the most sense, but I wonder what a transaction restart would look like under that framework?  It seems that not only would the tx need to restart, but it would need to restart at the first thread pool of the staged processor.

 

I am not convinced that a persistence layer that is using a locking strategy is suitable for a non-blocking single threaded process.  If any lock request blocks, then the entire server will halt without a chance to resume.  This seems unworkable.  My other concern with this scenario is that the latency involved in disk IO can be quite large and is not necessarily predicable, e.g., an incremental write could occur at an arbitrary moment.  Such latency could cause the server to drop messages, which also seems unworkable.  Please let me know if I am wrong, but I do not see how jdbm could be used in such an environment, especially in conjunction with a locking strategy for managing resource access contention.

 

However, I would also like to talk more about the 2PL locking model.  I have been designing based on the early work by Gray and Bayer covering 2PL, intention and implicit locking, and online deadlock detection algorithms.  This is quite different from java.util.concurrent in two ways.  First, the lock modes are not just READ (Share) and WRITE (Exclusive), but also include intention and implicit lock modes.  Second, deadlocks are detected using an induced WAITS_FOR graph among the transactions that are blocked.  There is no comparable feature in java.util.concurrent – the classes in those packages are not design to support deadlock detection.

 

I have been writing up the package semantics for the 2PL support [1].  Some feedback on this would be useful.

 

Thanks,

 

-bryan

 

[1] http://cvs.sourceforge.net/viewcvs.py/cweb/concurrent/src/java/org/CognitiveWeb/concurrent/locking/package.html?rev=1.3&view=log

 


From: jdbm-developer-admin@lists.sourceforge.net [mailto:jdbm-developer-admin@lists.sourceforge.net] On Behalf Of Kevin Day
Sent: Tuesday, March 28, 2006 12:06 AM
To: JDBM Developer listserv
Subject: re[2]: [Jdbm-developer] 2PL: transactions, threads and locking (rese nd!)

 

Alex-

 

OK - I wrote a big long email explaining my thoughts, and finally managed to work myself around to understanding where you are coming from...

 

Suspend and resume does indeed take care of the issue.  If each thread has a single active transaction, then that thread will block as soon as it hits a lock that doesn't belong to that transaction.  The key is that if a tx is blocked, it can't possibly be switched to a different thread (this is what the suspend call is providing for), which ensures that we can't have multiple threads making calls against the same tx at the same time.  At this point, blocking becomes a matter of simple wait/notify on the lock object - unless we want to implement some sort of priority based notification (which we might...).

 

This means that using thread local storage for the transaction does make sense.  I also think that the transaction itself will need to store it's associated thread for use in checks to ensure that the user doesn't continue to use a tx after it suspends it.  I suppose another thing that could be done here would be to make the resume call implicit (we are already going to have to check each Transaction.insert/update/delete/commit call to ensure that the current thread is correct).

 

Not sure about the performance implications of actually performing that check for each call...

 

Thanks guys, sorry to slow the process down.

 

- K

 

 

> Kevin Day wrote:
Interesting.  Does this imply that there can only be one executing Tx per thread at any given point in time?  I think this starts to break down, though, because you can't release the locks when you suspend a Tx (not without viloating 2PL, anyway). I don't understand.  Can you provide an example of what you mean?

No matter what Bryan does, he still has to deal with the fact that a single thread could wind up needing to block itself (by definition, this would be deadlock).  This scenario is pretty easy to detect, and should probably abort one of the transactions (it implies that the application developer has not designed their threading/transaction handling properly). In the scheme I was proposing, a transaction holds locks, not a thread.   If a transaction holds a lock, it cannot block itself.  You can only get into a deadlock situation with two or more transactions.

(If you want locks for synchronizing threads, you can use java.util.concurrency or something alike)

alex
<

 

------------------------------------------------------- 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 Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer