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...
thanks,
bryan
