You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-commits@db.apache.org by mi...@apache.org on 2011/03/16 17:48:10 UTC
svn commit: r1082197 -
/db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
Author: mikem
Date: Wed Mar 16 16:48:10 2011
New Revision: 1082197
URL: http://svn.apache.org/viewvc?rev=1082197&view=rev
Log:
DERBY-3993 With IBM 1.6 T_RawStoreFactory fails with There should be 0 observers, but we still have 1 observers on Win 2K
The problem will only show up in SANE builds as that is the only time we do
the sanity check.
Xact.doComplete() is called near the end of the transaction to take care of any
cleanup prior to committing or aborting the transaction.
It calls notifyObservers(commitOrAbort) and it expects on return that each
observer has been notified, and all the observers are coded
to delete themselves from the observer list as part of this process. It then
asserts that the list should be empty on return.
The problem is that one of the DropOnCommit observer as part of it's
processing manages to add another observer to the list. I am guessing that the
problem becomes intermittent because either different
JVM's/memory layouts/hash algorithms
result in the order processing of the observer list to be different,
or different implementations handle the adding of an observer to the list
while scanning the list differently. There is nothing in the Observable
javadoc that guarantees and order or says anything about expected behavior
of notifyObservers() execution if another observer is added during the
execution so I don't think it is a jvm bug.
In my case in order to process a drop of a container marked drop on commit the
raw store interface requires it to first be opened. The code adds
a TruncateOnCommit as part of this open as that layer of the code does not
know why it is being opened. I believe it is this "new" TruncateOnCommit
observer which is left on the observer queue. Adding an extra notify to the
drop on commit processing seems to fix the unit test, I'll see if that causes
any problems in the full set of tests.
Modified:
db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
Modified: db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
URL: http://svn.apache.org/viewvc/db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java?rev=1082197&r1=1082196&r2=1082197&view=diff
==============================================================================
--- db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java (original)
+++ db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java Wed Mar 16 16:48:10 2011
@@ -72,25 +72,40 @@ public class DropOnCommit extends Contai
@see java.util.Observer#update
*/
public void update(Observable obj, Object arg) {
+
if (SanityManager.DEBUG) {
if (arg == null)
- SanityManager.THROWASSERT("still on observr list " + this);
+ SanityManager.THROWASSERT("still on observer list " + this);
}
- if (arg.equals(RawTransaction.COMMIT) || arg.equals(RawTransaction.ABORT)) {
+ if (arg.equals(RawTransaction.COMMIT) ||
+ arg.equals(RawTransaction.ABORT)) {
RawTransaction xact = (RawTransaction) obj;
try {
+
if (this.isStreamContainer)
- xact.dropStreamContainer(identity.getSegmentId(), identity.getContainerId());
+ xact.dropStreamContainer(
+ identity.getSegmentId(), identity.getContainerId());
else
xact.dropContainer(identity);
+
} catch (StandardException se) {
+
xact.setObserverException(se);
+
}
obj.deleteObserver(this);
+
+ // DERBY-3993
+ // make sure any observer that may have been added by either
+ // dropContainer() or dropStreamContainer() is also handled.
+ // The calling notifyObservers() call from Xact.doComplete()
+ // may not "see" new observers added during processing of the
+ // initial observer list.
+ xact.notifyObservers(arg);
}
}
}