Community
Participate
Working Groups
See TransactionCommitContext.updateInfrastructure(OMMonitor). The call repository.getLockManager().unlock(transaction) is through the wrong interface, bypassing the logic that updates the LockArea. Will fix this together with all the other locking stuff.
The original problem reported here was fixed as part of bug 353691. But another look at the code has me wondering what happens if the client has a persistent WRITE lock on an object X, has autoReleaseLocks disabled, and commits X. It looks like the commit logic will release that WRITE lock in memory by calling TransactionCommitContext.unlockObjects from TransactionCommitContext.updateInfrastructure. Thus we can end up having a lock that's been removed from memory but still exists in the persisted lockArea. I also wonder what happens if autoReleaseLocks is *enabled*, the client has X WRITE-locked explicitly and persistently, and then he commits X. From the server-side tx code it looks like X gets write-locked a 2nd time, and then released. Maybe this work OK because locks are counted; i.e. if the same view locks an object twice, then it needs to unlock it twice. But I don't think we have any tests verifying this behavior. So... needs further investigation, and some new testcases.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
