354454 – Recursive locking (tree locking)

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

Bug 354454 - Recursive locking (tree locking)

Summary: Recursive locking (tree locking)

Status:	CLOSED FIXED

Alias:	None

Product:	EMF
Classification:	Modeling
Component:	cdo.core (show other bugs)
Version:	4.1
Hardware:	All All

Importance:	P3 enhancement (vote)
Target Milestone:	---
Assignee:	Caspar D.
QA Contact:	Eike Stepper

URL:
Whiteboard:	Power to the People
Keywords:

Duplicates (1):	270393 (view as bug list)
Depends on:	353691
Blocks:
	Show dependency tree

Reported:	2011-08-11 01:11 EDT by Caspar D.
Modified:	2012-12-31 02:06 EST (History)
CC List:	3 users (show)

See Also:

Flags:	stepper: review- stepper: review+

Attachments
Patch v1 (36.14 KB, patch) 2011-09-15 03:31 EDT, Caspar D.	no flags	Details \| Diff
Patch v2 (41.47 KB, patch) 2011-09-15 06:53 EDT, Caspar D.	no flags	Details \| Diff
Patch v3 (39.37 KB, patch) 2011-09-19 04:11 EDT, Caspar D.	no flags	Details \| Diff
Patch v4 (41.08 KB, patch) 2011-09-19 05:14 EDT, Eike Stepper	no flags	Details \| Diff
Patch v5 (48.61 KB, patch) 2011-09-19 23:09 EDT, Caspar D.	no flags	Details \| Diff
Patch v6 (41.52 KB, patch) 2011-09-20 04:31 EDT, Caspar D.	no flags	Details \| Diff
Show Obsolete (5) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Caspar D.

2011-08-11 01:11:28 EDT

Aim is to allow user to lock an object and all its eAllContents() with
a single call, and without having to load (or triggering the load of) all
the children on the client.

Comment 1 Caspar D.

2011-09-15 03:31:50 EDT

Created attachment 203386 [details]
Patch v1

SVN patch, not an Eclipse patch.

Comment 2 Caspar D.

2011-09-15 06:53:46 EDT

Created attachment 203400 [details]
Patch v2

Comment 3 Caspar D.

2011-09-15 06:54:32 EDT

Patch v2 is also an SVN patch...

Comment 4 Caspar D.

2011-09-19 04:11:43 EDT

Created attachment 203572 [details]
Patch v3

Comment 5 Eike Stepper

2011-09-19 05:14:22 EDT

Created attachment 203575 [details]
Patch v4

Comment 6 Eike Stepper

2011-09-19 05:24:59 EDT

LockingManagerTest.testRecursiveLock() fails in all legacy scenarios.

Please add syncing on the lock manager in (as discussed on Skype):

  LockManager.lock2(boolean, LockType, IView, Collection<? extends Object>, boolean, long)
  LockManager.unlock2(boolean, LockType, IView, Collection<? extends Object>, boolean)
  
Otherwise it looks good ;-)

Comment 7 Eike Stepper

2011-09-19 05:26:22 EDT

Oh, and please be so kind to add the recursice methods to CDOLock.

Comment 8 Caspar D.

2011-09-19 23:09:27 EDT

Created attachment 203631 [details]
Patch v5

Aborted attempt to introduce CDOObject.cdoRecursiveLock(LockType)

It turned out too problematic, because it requires an implementation
of isLocked and isLockedByOthers. How would this work for a recursive
lock? Presumably the lock would answer on behalf of its entire content
tree. But how can it? If the answer is to be computed on the server,
then we need a new signal. If the answer it computed locally, then
we need to fetch the lockstates for the entire content tree. But
what if the content tree changes? That implies that changes to the
*data* trigger special notifications to keep these recursive locks
up to date... I think that's way too complex, so I'm abandoning
this approach.

Comment 9 Caspar D.

2011-09-20 04:31:29 EDT

Created attachment 203649 [details]
Patch v6

Comment 10 Caspar D.

2011-09-21 07:11:10 EDT

Committed revision 9193.

Comment 11 Eike Stepper

2012-09-21 07:17:24 EDT

Closing.

Comment 12 Eike Stepper

2012-12-31 02:06:44 EST

*** Bug 270393 has been marked as a duplicate of this bug. ***