Community
Participate
Working Groups
I noticed that the CommitNotifications seem to be able to overtake each other when there are many commits (for the same object & feature) done quickly after each other. This is also the cause for bug #312404 (for which a workaround has been added). The problem is not only present in the CommitRunnables on the RepositorySynchronizer, but also in normal InvalidationRunnables (see screenshot), which might lead to IndexOutOfBoundsExceptions on the view or changes applied in wrong order. The problem is probably not limited to CommitNotifications and might not a bug but a feature of Net4J, so I'm unsure if this should be fixed at Net4J level.
Created attachment 181394 [details] Debug Screenshot On the screenshot you can see the InvalidationRunnable currently being processed which wants to modify object 259v559 and the InvalidationRunnable in the queue at [7] which wants to modify object 259v588.
Sorry, I meant InvalidationRunnable [7] modifies object 259v558. I noticed this behavior on both JVM and TCP connections.
Created attachment 181477 [details] Testcase
You're right in that I would see this as a feature of Net4j rather than a bug. That said, I'm inclined to see this as a bug in CDO. And it can probably only be fixed by changing the "id" of a commit from its time stamp to a sequential number (but keep the time stamp as a normal field, of course).
I've added CDOCommitInfo.getPreviousTimeStamp() to enable waiting for outstanding data...
NOTE: This fix changes the DB schema. Existing DBs have to be recreated!!!
Created attachment 181595 [details] Patch v1 - for future reference This patch adds the "previous time" to CDOCommitInfo.
Created attachment 181655 [details] Fix v1 Not yet tested.
Created attachment 181656 [details] Testcase v2
Pascal, my fix va does not break anything else, but the test case you've attached passes also without that one. Can we discuss this via Skype tomorrow?
Created attachment 181727 [details] Fix v2 The testcase fails fine here (with or without fix), so I updated your fix. Testcase works fine now.
Created attachment 181729 [details] Testcase v3 Updated Testcase (checks if also the last commit arrived).
Created attachment 181801 [details] Combined patch - ready to be committed Congratulations Pascal, your first CVS commit ;-)
Created attachment 181805 [details] Combined patch v2 This entirely different patch moves the *complete* invalidation processing into the InvalidationRunnable, including reviseOldRevisions, setLastUpdateTime and fireSessionInvalidationEvent! This not only makes the separate "sequence ordering" in the RepositorySynchronizer unnecessary, but rather solves potential issues with other IListeners on the session.
Committed combined patch v2 to HEAD. Pascal, can you please test the raw replication again?
The Testcase also works fine with the optimized fix :)
Thank you for testing, Pascal ;-)
Encountered deadlocks.
Created attachment 182382 [details] Additional Fix I ran into deadlocks so I had to use more restrictive locking. The deadlock occurred because the invalidation lock of the commiting transaction was released but not all views yet invalidated, while another transaction (which was not yet invalidated) already grabbed the invalidation lock.
Created attachment 182548 [details] Additional Fix v2 - ready to be committed I removed the latch!=null checks. Please go ahead...
Committed additional fix v2 to HEAD.
Available in R20110608-1407
