It is just that it is not appropriate to a 2PL lock subsystem. You can of course use another lock subsystem.
2PL does permit applications to release locks incrementally, rather than just all at once, but my impression is that locks tend to be released in large groups.
[mailto:email@example.com] On Behalf Of Alex Boisvert
Sent: Wednesday, March 29, 2006 3:57 PM
To: Kevin Day
Cc: JDBM Developer listserv
Subject: Re: [Jdbm-developer] re: 2PL: transactions, threads <s nip>
Kevin Day wrote:
On the re-entrancy comments, I'd like to reword what I think you are proposing just to make sure I understand: Because under 2PL we would never perform a release on a lock unless we are releasing all locks for a given transaction, it matters not at all if the same transaction makes 1, 5 or 10 lock requests on the same resource. If subsequent requests are no-ops, then 2PL guarantees that we won't have re-entrancy issues related to iterative programming, etc...
This is my understanding