This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 49609 - Enforce no Document Locks in beginTrans
Summary: Enforce no Document Locks in beginTrans
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-27 19:18 UTC by Pavel Buzek
Modified: 2007-09-26 09:14 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Buzek 2004-09-27 19:18:08 UTC
There could be a ThreadLocal variable created by
the editor module and set once any document gets
locked by a thread.
Javacore could check that variable value and throw
assertion failure if it's set (document is locked).
The ThreadLocal variable could be published in
system properties (dirty as there should be just
string values for system properties but should
work fine for this purpose).
The whole checking thing should be done as asserts
so it's not done in final release.
Comment 1 Jaroslav Tulach 2004-09-28 08:46:33 UTC
If there was a module that depends on javacore and editor and can use
their friend API then such module would be good candidate for bridging
the ThreadLocal variable from document to mdr.
Comment 2 Miloslav Metelka 2004-09-30 18:46:30 UTC
OK so we will make a friend API in javacore for this and the editor
module will call it actively. The only problem with this is that once
we split the editor module we will have to do the same thing
(registering of the ThreadLocal reference) for each such "friendship".
But IMHO that's acceptable.
Changed to TCA according to the previous discussion but it should be
relatively easy to implement.
Comment 3 Miloslav Metelka 2004-10-04 11:00:23 UTC
The editor side is ready as well. All the calls to render() and
runAtomic() (unfortunately the AbstractDocument.readLock() and
writeLock() are final so I cannot track calls to these naturally) will
 increase the lock counter which would be caught on the javacore side
and reported.
 I have tested this manually as well as I've run the commit-validation
and unit and qa-functional tests on the editor and they pass well. I
was trying to run javacore tests as well but I've ended up with issue
#49877 but anyway the tests prior shutdown were not broken by the
integration so it seems to be ok.

 Integrated into main trunk:
Checking in arch/arch-editor.xml;
/cvs/editor/arch/arch-editor.xml,v  <--  arch-editor.xml
new revision: 1.12; previous revision: 1.11
done
Processing log script arguments...
More commits to come...
Checking in libsrc/org/netbeans/editor/BaseDocument.java;
/cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v  <-- 
BaseDocument.java
new revision: 1.109; previous revision: 1.108
done
Processing log script arguments...
More commits to come...
Checking in src/org/netbeans/modules/editor/EditorModule.java;
/cvs/editor/src/org/netbeans/modules/editor/EditorModule.java,v  <-- 
EditorModule.java
new revision: 1.109; previous revision: 1.108

It should be all from the editor point of view. If there is nothing
more on javacore side the issue can be closed.
Comment 4 Martin Matula 2004-10-04 17:32:37 UTC
Implemented in javacore.

Checking in src/org/netbeans/modules/javacore/ExclusiveMutex.java;
/cvs/java/javacore/src/org/netbeans/modules/javacore/ExclusiveMutex.java,v
 <--  ExclusiveMutex.java
new revision: 1.29; previous revision: 1.28
done
Comment 5 Quality Engineering 2007-09-20 09:54:49 UTC
Reorganization of java component