[concurrency-interest] Owned Locks

Doug Lea dl@cs.oswego.edu
Sat, 26 Jul 2003 08:03:53 -0400

Thanks for the comments!

We intentionally left out two variants of possible lock-based
interfaces -- transaction locks as you mentioned, as well as
"upgradable" read-write locks. Both for the same reasons: We are less
confident about the best forms they should take, most of the desired
effects can usually be obtained using the APIS we DO include, and we
don't know of standardized implementations with broad enough
applicability to include.

For transaction-style locks the most typical scenario is to use a
transaction identifier that is associated with the current thread.  As
in your:

> If for example in a multi threaded client server application, where each 
> request may
> be handled by a thread in a thread pool, and a session id is allocated 
> to a particular
> client, thread based locking is not too useful. Locking based on the 
> session id would
> be ideal.

If you set a ThreadLocal (perhaps in beforeExecute) to the current
session ID, then you can elide the argument in lock() etc, and use the
ordinary Lock API (with, of course, your own special implementation.)
I believe this is pretty common, although does not always nicely
apply. But doing more than this at the API level starts intruding into
other Java transaction package APIs, and would invite us to consider
support for database and distributed lock frameworks, which is clearly
outside our scope.

While I'm at it (and in the process, implicitly answering a related
question someone had a few weeks ago), we had similar discussions
about supporting three- or five- flavor schemes for upgradable
ReadWrite locks (see e.g., Gray and Reuter's Transaction book), and
decided against defining them at least for JSR-166.  Both are still
candidates for any follow-up extensions to j.u.c.  We are hoping that
releasing the basic stuff in j.u.c that we do provide will help propel
people to experiment with such things, to release non-standardized
packages (like I did with dl.u.c), and on the basis of experience,
eventually standardize.