[concurrency-interest] Lock Manager

Doug Lea dl@cs.oswego.edu
Wed, 5 Nov 2003 07:40:29 -0500

We did intentionally omit transaction support of all kinds from
JSR-166. Adam is right to press us about a simple LockManager anyway,
because it is at the borders of something that can be useful even in
non-transactional settings. But still, as others have already noted,
there is a lot of variablility in desired policy/mechansism/usage,
which we don't know how to deal with so conservatively omit.

I do think that lightweight transaction frameworks are among the next
major steps in Java concurrency support. But there are still lots of
questions about how to go about this that are probably best answered
by building pre-standardized ones and then standardizing based on

While I'm at it: The currently posted APIs as of today (modulo
cosmetic touch-ups) are the ones that will appear in the first public
beta of Sun JDK1.5.0, due out the first week of February. (This week
is internal API freeze deadline for beta1.) Further changes before
final 1.5.0 release are still possible, and WILL happen if people
discover serious flaws or omissions.  For example, Dawid's complaints
last month caused us to realize that we didn't have a good way to run
tasks with special security needs, which we felt was serious enough to
remedy (although in a way that is probably still not entirely to
Dawid's liking :-). Plus, we do still want to encourage comments and
suggestions of all kinds. Some of them, like transaction support,
might end up as the basis for follow-on work.