EVALUATION
replace doesn't call remove then insertString as it first grabs a writeLock, then does the mutation. insertString and remove both also attempt to grab a writeLock, hence the inability for replace to call them.
There is really no reason why we don't allow multiple calls to writeLock from the same thread that grabbed the lock. We just need to make sure non of the listeners attempt to mutate the Document, as such we will now allow additional writeLocks to be grabbed from the first thread that obtained the writeLock as long as not in the middle of document notification. The documentation for writeLock/writeUnlock will be updated to:
The documentation of writeLock will change to:
/**
* Acquires a lock to begin mutating the document this lock
* protects. There can be no writing, notification of changes, or
* reading going on in order to gain the lock. Additionally a thread is
* allowed to gain more than one <code>writeLock</code>,
* as long as it doesn't attempt to gain additional <code>writeLock</code>s
* from within document notification. Attempting to gain a
* <code>writeLock</code> from within a DocumentListener notification will
* result in an <code>IllegalStateException</code>. The ability
* to obtain more than one <code>writeLock</code> per thread allows
* subclasses to gain a writeLock, perform a number of operations, then
* release the lock.
* <p>
* Calls to <code>writeLock</code>
* must be balanced with calls to <code>writeUnlock</code>, else the
* <code>Document</code> will be left in a locked state so that no
* reading or writing can be done.
*
* @exception IllegalStateException thrown on illegal lock
* attempt. If the document is implemented properly, this can
* only happen if a document listener attempts to mutate the
* document. This situation violates the bean event model
* where order of delivery is not guaranteed and all listeners
* should be notified before further mutations are allowed.
*/
protected synchronized final void writeLock();
/**
* Releases a write lock previously obtained via <code>writeLock</code>.
* After decrementing the lock count if there are no oustanding locks
* this will allow a new writer, or readers.
*
* @see #writeLock
*/
protected synchronized final void writeUnlock();
scott.violet@eng 2001-05-15
I have added stack trace for exception thrown in Pilsen CE build 010620_1.
This should help us to identify this issue, if we will search it anytime.
###@###.### 2001-06-21
|
Java
