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

Bug 354454

Summary:

Recursive locking (tree locking)

Product:

[Modeling] EMF

Reporter:

Caspar D. <caspar_d>

Component:

cdo.core

Assignee:

Caspar D. <caspar_d>

Status:

CLOSED FIXED

QA Contact:

Eike Stepper <stepper>

Severity:

enhancement

Priority:

CC:

saulius.tvarijonas, smcduff, stepper

Version:

4.1

Flags:

stepper: review-
stepper: review+

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Power to the People

Bug Depends on:

353691

Bug Blocks:

Attachments:

Description	Flags
Patch v1	none
Patch v2	none
Patch v3	none
Patch v4	none
Patch v5	none
Patch v6	none

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. ***