Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354115

Summary:	Persistent locks aren't properly released when autoReleaseLocksEnabled==true
Product:	[Modeling] EMF	Reporter:	Caspar D. <caspar_d>
Component:	cdo.core	Assignee:	Caspar D. <caspar_d>
Status:	ASSIGNED ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	saulius.tvarijonas
Version:	4.13
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Caspar D.

2011-08-08 05:40:49 EDT

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.

Comment 1 Caspar D.

2011-08-18 05:23:38 EDT

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.

Comment 2 Eike Stepper

2012-08-14 22:52:51 EDT

Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.

Comment 3 Eike Stepper

2013-06-29 12:18:42 EDT

We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.

Comment 4 Eike Stepper

2015-07-14 02:13:32 EDT

Moving all open bugzillas to 4.5.

Comment 5 Eike Stepper

2016-07-31 00:56:27 EDT

Moving all unaddressed bugzillas to 4.6.

Comment 6 Eike Stepper

2017-12-28 01:20:59 EST

Moving all open bugs to 4.7

Comment 7 Eike Stepper

2019-11-08 02:13:02 EST

Moving all unresolved issues to version 4.8-

Comment 8 Eike Stepper

2019-12-13 12:43:58 EST

Moving all unresolved issues to version 4.9

Comment 9 Eike Stepper

2020-12-11 10:36:47 EST

Moving to 4.13.