db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Pendleton <bpendle...@amberpoint.com>
Subject Re: Table Intent locks not optimized/collapsed if table-level lock already held?
Date Thu, 08 Dec 2005 01:16:29 GMT
Mike Matrigali wrote:
> the logic is slightly different dependent on isolation level,
> what isolation level are you running.  All the code gets the
> table level intent lock first, and if that succeeds then checks
> if it has covering locks such that it does not need to get row
> locks.
> The code is in the lockContainer() routines in
> opensource/java/engine/org/apache/derby/impl/store/raw/xact/RowLock*.java.

I am running in the default (Read Committed) isolation level, so
I've been looking at the code in RowLocking2.java.

By stepping through the lockContainer() code it appears that:
1) I successfully get the Container IX lock
2) Then the code checks to see if I've already got the Container X
    lock, and it decides that yes, I do. (isLockHeld returns true).
3) Then the code calls lf.unlockGroup() with the comment
    //release any container group locks becuase CX container lock will cover everthing.
4) I end up getting down to LockSpace.unlockGroup(), but at the
    very start of this routine the variable "dl" is null, so I take
    the "if (dl == null) return;" path.

So the lock code seems to be taking the right basic path, but it
isn't finding the IX lock to release it.

Is it possible that the problem involves this code at the start
of RowLocking2.lockContainer:

         // for cursor stability put read locks on a separate lock chain, which
         // will be released when the container is unlocked.
         Object group =
             forUpdate ? ((Object) t) : ((Object) container.getUniqueId());

Since forUpdate is true in my case, I attach the IX lock to my
transaction, but then, a few lines later, when I try to release
that IX lock because it's covered by the X lock, we simply call

    lf.unlockGroup(t.getCompatibilitySpace(), container.getUniqueId());

which means that "group" is set to "t" when I acquire the lock, but
it is set to "container.getUniqueId()" when I try to release the
lock, and hence the lock is not found.

Or maybe I'm totally barking up the wrong tree...



View raw message