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: r1134336 -
 /db/derby/code/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
Date: Fri, 10 Jun 2011 15:00:49 -0000
To: derby-commits@db.apache.org
From: mikem@apache.org
Message-Id: <20110610150049.54CCA238897D@eris.apache.org>

Author: mikem
Date: Fri Jun 10 15:00:48 2011
New Revision: 1134336

URL: http://svn.apache.org/viewvc?rev=1134336&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

backporting change #1082197 from trunk to 10.6 branch.

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/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java

Modified: db/derby/code/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java
URL: http://svn.apache.org/viewvc/db/derby/code/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java?rev=1134336&r1=1134335&r2=1134336&view=diff
==============================================================================
--- db/derby/code/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java (original)
+++ db/derby/code/branches/10.6/java/engine/org/apache/derby/impl/store/raw/data/DropOnCommit.java Fri Jun 10 15:00:48 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);
 		}
 	}
 }