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

Bug 351793

Summary:

Enhance LockMgr with write options

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

Version:

4.1

Flags:

stepper: review+
stepper: review+

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Power to the People

Bug Depends on:

Bug Blocks:

352330

Attachments:

Description	Flags
Patch v1	none
Patch v2	none
Patch v3	none
Patch v4	none
Patch v5	none
Patch v6	none
Patch v7	none
Patch v8	none
Patch v9	none
Patch v10 - ready to be committed	none
Patch (JavaDocs)	none
Patch v2 (JavaDocs + logic)	none
Patch v3 (JavaDocs + logic)	none

Description Caspar D.

2011-07-12 02:24:51 EDT

A write option (or write reservation) is a lock that prevents other
views from obtaining a write lock, but does not prevent others from
obtaining read locks. How is it different from a read lock? A write
option can only be held by *one* view. Why do we need this? So that
apps can prevent writes without preventing read locking.

Patch coming up.

Comment 1 Caspar D.

2011-07-12 02:37:58 EDT

Created attachment 199467 [details]
Patch v1

Incomplete, only contains a crude version of the new lockMgr.
Changes to client-side API not yet done.

Comment 2 Caspar D.

2011-07-12 04:19:09 EDT

Created attachment 199472 [details]
Patch v2

All existings tests passing now, except those verifying persistent
locks. New tests (verifying WRITE_OPTION behavior) yet to be done.

Comment 3 Caspar D.

2011-07-12 05:46:41 EDT

Created attachment 199477 [details]
Patch v3

All existing tests passing now.

TBD:
- Client-side API
- New tests for WRITE_OPTION locks

Comment 4 Caspar D.

2011-07-13 01:35:51 EDT

Created attachment 199539 [details]
Patch v4

Refactored changes based on new insight that there are no API constraints
on changes to an internal class.

Comment 5 Caspar D.

2011-07-13 01:58:55 EDT

Created attachment 199541 [details]
Patch v5

Refactored again; base class now genericized, and moved to net4j.util

Comment 6 Caspar D.

2011-07-13 06:01:40 EDT

Created attachment 199558 [details]
Patch v6

Functionality complete, I believe.

TBD: Performance optimizations, especially view-to-locks lookup

Comment 7 Caspar D.

2011-07-13 07:21:04 EDT

Created attachment 199567 [details]
Patch v7

Forgot to persist those write options! Better now :-)

Comment 8 Caspar D.

2011-07-18 04:51:48 EDT

Created attachment 199814 [details]
Patch v8

Performance optimizations

Comment 9 Eike Stepper

2011-07-22 02:09:33 EDT

Created attachment 200142 [details]
Patch v9

I broke the tests ;-(

Comment 10 Eike Stepper

2011-07-22 02:43:46 EDT

Created attachment 200146 [details]
Patch v10 - ready to be committed

Good work!

Comment 11 Eike Stepper

2011-07-22 02:44:41 EDT

I can approve the patch when Javadoc has been added to CDOObject.cdoWriteOption() and RWOLockManager ;-)

Comment 12 Eike Stepper

2011-07-22 02:45:15 EDT

Actually I did approve it and rely on your promise to add JavaDocs ;-)

Comment 13 Caspar D.

2011-07-22 02:50:37 EDT

Committed revision 8806.

Not resolving yet, cause JavaDocs yet to be done.

Comment 14 Caspar D.

2011-07-26 03:04:34 EDT

Created attachment 200333 [details]
Patch (JavaDocs)

Added JavaDocs.

Comment 15 Eike Stepper

2011-07-26 03:30:12 EDT

> a read lock prevents write locks by others, but allows read locks by others, and is therefore <b>non-exclusive</b>

How are write option requests impacted?

> a write lock prevents read locks by others and write locks by others, and is therefore <b>exclusive</b>

How are write option requests impacted?

> a write option prevents write locks by others and write options by others, but allows read locks by others, and is therefore <b>exclusive</b>

Comment 16 Caspar D.

2011-07-26 03:50:13 EDT

(In reply to comment #15)
> > a read lock prevents write locks by others, but allows read locks by others, and is therefore <b>non-exclusive</b>
> 
> How are write option requests impacted?

They're not.

> > a write lock prevents read locks by others and write locks by others, and is therefore <b>exclusive</b>
> 
> How are write option requests impacted?
> 

They're not.. but in this case I your question makes me realize that
this is a mistake. A write lock must prevent write options by others.

Will amend both the docs and the logic.

Comment 17 Eike Stepper

2011-07-26 03:51:15 EDT

Excellent ;-)

Comment 18 Caspar D.

2011-07-26 04:25:07 EDT

Created attachment 200342 [details]
Patch v2 (JavaDocs + logic)

Comment 19 Caspar D.

2011-07-26 05:40:22 EDT

Created attachment 200345 [details]
Patch v3 (JavaDocs + logic)

Comment 20 Caspar D.

2011-07-26 06:20:46 EDT

Committed revision 8820.

Comment 21 Caspar D.

2011-07-26 06:24:10 EDT

Resolving as FIXED.

Comment 22 Eike Stepper

2012-09-21 07:16:32 EDT

Closing.