Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r1082197 -
 /db/derby/code/trunk/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
Date: Wed, 16 Mar 2011 16:48:10 -0000
To: derby-commits@db.apache.org
From: mikem@apache.org
Message-Id: <20110316164811.1BEE6238896F@eris.apache.org>

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);
 		}
 	}
 }