Bug 206907 - Add BaseDocument.runExclusive()
Add BaseDocument.runExclusive()
Product: editor
Classification: Unclassified
Component: Actions/Menu/Toolbar
PC All
: P2 (vote)
: 7.2
Assigned To: Miloslav Metelka
Depends on:
Blocks: 206134
  Show dependency treegraph
Reported: 2012-01-04 14:22 UTC by Miloslav Metelka
Modified: 2012-03-27 09:15 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT

Diff of the proposed change (25.42 KB, patch)
2012-03-12 11:21 UTC, Miloslav Metelka
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Miloslav Metelka 2012-01-04 14:22:35 UTC
Issue 21237 changed the BaseDocument.runAtomic() handling. Originally it was like this:
1. Document's writeLock().
2. Process document changes made by Runnable of runAtomic().
3. writeUnlock().
4. CloneableEditorSupport.notifyModify()
  a) file-lock acquired => do nothing.
  b) file-lock refused => Undo changes made by just performed runAtomic().

Tests require that notifyModify() is called without document's write-lock (although there's likely no client relying on that).
Although 3. and 4b) follow closely there could be another client who could acquire writeLock() between 3. and 4b) and do modifications which is inconsistent.

Therefore I have changed the behavior to a more logical state:
1. CloneableEditorSupport.notifyModify()
  a) file-lock acquired => continue.
  b) file-lock refused => continue but throw BadLocationException on any insert/remove attempt.
2. Document's writeLock().
3. Process document changes made by Runnable of runAtomic().
4. writeUnlock().

However many clients called runAtomic() although they did not do any document modification. This caused readonly files beeping (modification refused) or Clearcase attempting to checkout file.
These occurrences were rewritten to use Document.render() where possible. However there are clients such as lexer that require to do some operations under exclusive access to document and they were using runAtomic() for that purpose. However now this is no longer desirable.

 A new BaseDocument.runExclusive() method should be created with the following contract:
1) Caller thread of runExclusive() would be granted an exclusive access to the document (other threads calling Document.render() or runAtomic() would wait). For AbstractDocument implementations AbstractDocument.writeLock() would be called to gain exclusivity but it's not required generally.
2) Readonly access to the document allowed only. All modification attempts would fail.
3) Nested runExclusive() call is possible.
4) It's not allowed to call runExclusive() from Runnable passed to Document.render().
5) It's allowed to call runExclusive() from Runnable passed to runAtomic().
Comment 1 Miloslav Metelka 2012-03-12 11:21:39 UTC
Created attachment 116593 [details]
Diff of the proposed change
Comment 2 Miloslav Metelka 2012-03-12 11:25:15 UTC
Since o.n.editor.BaseDocument is not a desirable place for API I have implemented the functionality through an API in editor.lib2.

I would like to ask for a fasttrack API review. Thanks.
Comment 3 Miloslav Metelka 2012-03-27 09:15:32 UTC

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo