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