Community
Participate
Working Groups
If failure on previous commit was encountered, then next commit doesn't invalidate the session, from which commit was executed.
Created attachment 198248 [details] Test case Test case attached. First test illustrates that invalidation on session was not executed. Second case shows how bad it is with locking elements after such invalidation failure. Client becomes hanged (until next commit to server)
Created attachment 198398 [details] TestCase + patch v2
Client side transaction invalidates and synchronizes commit updates by the previous commit time received from the server. Thus we need to ensure to notify commits, which has *successful* previous commit time. Patch removes lastIssuedTimeStamp and uses time stamp of the last finished transaction.
Changing to 4.1 to ensure that the fix will "last". Please clone this bugzilla to 4.0 if you want a maintenance fix, too.
Created attachment 198999 [details] Patch v3 Your fix looks good. But the 2. test would block the Hudson build forever in case of regressions. Please make it fail after DEFAULT_TIMEOUT_EXPECTED. Then request a review again, please...
Cannot timeout particular test in API level, because lock implementation by itself uses waitForUpdate without timeout.
(In reply to comment #6) > Cannot timeout particular test in API level, because lock implementation by > itself uses waitForUpdate without timeout. I'll approve this one when yo've filed a separate bug for the above issue in the lock implementation ;-)
Added bugzilla https://bugs.eclipse.org/bugs/show_bug.cgi?id=350985
Committed to trunk 8579 (fix), 8580 (junit test)
I assume you've only accidentally asked for a review again.
Hmm... I haven't asked for review (at least on purpose). It is already committed :)
Closing.