Bug 357613 - Optionally make WRITE_OPTIONs mandatory
Summary: Optionally make WRITE_OPTIONs mandatory
Status: ASSIGNED
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Caspar D. CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-14 06:10 EDT by Caspar D. CLA
Modified: 2020-12-11 10:45 EST (History)
2 users (show)

See Also:
stepper: review-


Attachments
Patch v1 (27.73 KB, patch)
2011-10-11 06:00 EDT, Caspar D. CLA
no flags Details | Diff
Patch v2 (29.54 KB, patch)
2011-10-11 06:18 EDT, Caspar D. CLA
no flags Details | Diff
Patch v3 (61.67 KB, patch)
2011-10-11 07:28 EDT, Caspar D. CLA
no flags Details | Diff
Patch v4 (regular patch, not an Eclipse patch) (51.32 KB, patch)
2011-11-08 01:33 EST, Caspar D. CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Caspar D. CLA 2011-09-14 06:10:30 EDT
Bug 351793 introduced the WRITE_OPTION type of lock. It would 
be nice if a repository could be configured to require a lock
requester to own a WRITE_OPTION before granting a WRITE lock.
That way, this type of lock would become of informational value
in addition to preventing writes by others. That is, if
WRITE_OPTIONS are mandatory, and noone is holding a
WRITE_OPTION, then that indicates that noone is planning to
perform a write; or at least noone objects to others writing.
Comment 1 Eike Stepper CLA 2011-09-19 01:06:01 EDT
Sounds good.
Comment 2 Caspar D. CLA 2011-10-11 05:21:08 EDT
The subtlety with this bug is that when the lockmanager rejects
a lockrequest because the requester doesn't have a write option,
there is no point in suspending the calling thread...
Comment 3 Caspar D. CLA 2011-10-11 05:21:51 EDT
(In reply to comment #2)
> The subtlety with this bug is that when the lockmanager rejects
> a lockrequest because the requester doesn't have a write option,
> there is no point in suspending the calling thread...

And that's different from the existing scenarios, where it always
makes sense to suspend the caller up to the timeout that he's passed
as an argument.
Comment 4 Caspar D. CLA 2011-10-11 06:00:59 EDT
Created attachment 204936 [details]
Patch v1

Works, but lockManager always throws TimeoutRuntimeEx, even if the
failure is of the new type, i.e. because the caller doesn't hold a
writeOption. This isn't quite right. New exception type?
Comment 5 Caspar D. CLA 2011-10-11 06:18:30 EDT
Created attachment 204937 [details]
Patch v2

Added config item in cdo-server.xml
Comment 6 Caspar D. CLA 2011-10-11 07:28:51 EDT
Created attachment 204945 [details]
Patch v3

Reworked LockObjectsResult to use an Enum to indicate the 
result of the locking operation. This is certanly better than
adding another boolean (we had 3 already).
Comment 7 Caspar D. CLA 2011-11-08 01:33:03 EST
Created attachment 206565 [details]
Patch v4 (regular patch, not an Eclipse patch)

This is a regular patch, generated by git. Apply with 'patch -p1'.
Comment 8 Caspar D. CLA 2011-11-08 05:36:32 EST
I just discovered that Git itself can process the patch, no need
for GNU patch. Just run 'git apply /patch/to/the/patch.txt'.
Comment 9 Caspar D. CLA 2011-11-08 23:05:46 EST
Please apply patch with 

  # git apply /path/to/the/patch.txt
Comment 10 Eike Stepper CLA 2012-01-31 00:38:41 EST
I can not apply this patch ;-(

$ git apply c:/develop/patches/git-patch-357613.txt
c:/develop/patches/git-patch-357613.txt:602: trailing whitespace.
 *
c:/develop/patches/git-patch-357613.txt:834: trailing whitespace.
 *
error: patch failed: plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/LockingManagerTest.java:17
error: plugins/org.eclipse.emf.cdo.tests/src/org/eclipse/emf/cdo/tests/LockingManagerTest.java: patch does not apply
error: patch failed: plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/concurrent/IRWOLockManager.java:21
error: plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/concurrent/IRWOLockManager.java: patch does not apply
error: patch failed: plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/concurrent/RWOLockManager.java:102
error: plugins/org.eclipse.net4j.util/src/org/eclipse/net4j/util/concurrent/RWOLockManager.java: patch does not apply
Comment 11 Eike Stepper CLA 2012-03-20 03:33:45 EDT
I still can't apply this patch, hence I can't review it. Rejecting for now.
Comment 12 Eike Stepper CLA 2012-08-14 22:56:21 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 13 Eike Stepper CLA 2013-06-27 04:06:40 EDT
Moving all outstanding enhancements to 4.3
Comment 14 Eike Stepper CLA 2014-08-19 09:24:26 EDT
Moving all open enhancement requests to 4.4
Comment 15 Eike Stepper CLA 2014-08-19 09:35:38 EDT
Moving all open enhancement requests to 4.4
Comment 16 Eike Stepper CLA 2015-07-14 02:19:11 EDT
Moving all open bugzillas to 4.5.
Comment 17 Eike Stepper CLA 2016-07-31 01:01:56 EDT
Moving all unaddressed bugzillas to 4.6.
Comment 18 Eike Stepper CLA 2017-12-28 01:10:27 EST
Moving all open bugs to 4.7
Comment 19 Eike Stepper CLA 2019-11-08 02:16:39 EST
Moving all unresolved issues to version 4.8-
Comment 20 Eike Stepper CLA 2019-12-13 12:43:55 EST
Moving all unresolved issues to version 4.9
Comment 21 Eike Stepper CLA 2020-12-11 10:45:38 EST
Moving to 4.13.