|
Re: CDO understanding commit conflicts [message #1832788 is a reply to message #1832743] |
Fri, 25 September 2020 04:48 |
|
I factored your snippet into an executable CDO test case:
@CleanRepositoriesBefore(reason = "Root resource access")
@CleanRepositoriesAfter(reason = "Root resource access")
public void testCommitConflict() throws Exception
{
CDOSession session = openSession();
CDOTransaction trans1 = session.openTransaction();
CDOTransaction trans2 = session.openTransaction();
String path1 = "/path1";
String path2 = "/path2";
CDOResource res1 = trans1.createResource(path1);
trans1.commit();
res1.setPath(path2);
CDOCommitInfo commitInfoA = trans1.commit();
trans2.waitForUpdate(commitInfoA.getTimeStamp());
trans2.getResource(path2).delete(null);
trans1.createResource("/someotherpath");
CDOCommitInfo commitInfoB = trans1.commit();
trans2.waitForUpdate(commitInfoB.getTimeStamp());
if (trans2.hasConflict())
{
fail("Conflicts: " + trans2.getConflicts());
}
trans2.commit();
}
It outputs the following:
Conflicts: CDOResource@OID1[CONFLICT]("/")
Both the addition and the deletion of a top-level resource create a change delta for the root resource "/". Depending on what transaction commits this change delta first this creates a conflict in the other transaction.
Note also that I added some waitForUpdate() calls. The commit() calls are executed completely sequentially and synchronously in one thread, but the resulting invalidations in the other views/transactions happen in background threads. The CDOView.waitForUpdate() method waits until all updates (i.e., invalidations) until the given time stamp are received by that view/transaction. Your code would cause a CommitConflictException in any case, but without the predictable timing via waitForUpdate() you can't be sure where the conflict is detected (on the server or already on the client).
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
Powered by
FUDForum. Page generated in 0.02884 seconds