Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] How to avoid LocalCommitConflictException
[CDO] How to avoid LocalCommitConflictException [message #1497231] Wed, 03 December 2014 17:04 Go to next message
Phil Wim is currently offline Phil WimFriend
Messages: 89
Registered: October 2013
Member
Hi there,

when exactly are LocalCommitConflictException thrown? I have multiple parallel transactions adding EObjects to the same EList/EReference of a parent EObject by AddCommands. After successful adding the EObject, the transaction gets committed and stays open. Then, more EObjects are added to the same EReference.

When I test it myself (RAP Env.) I have multiple browser rap instances running and adding in all session objects to the same EReference. All works like it supposed to.
In another multiuser case LocalCommitConflicExceptions are thrown sometimes. But I don't know why. I can't reproduce it.

Any tips for avoiding LocalCommitConflictException?

Thanks in advance
Philippe
Re: [CDO] How to avoid LocalCommitConflictException [message #1548090 is a reply to message #1497231] Mon, 05 January 2015 20:54 Go to previous messageGo to next message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi Phil,

You have to use either locks (pessimistic approach) or use a conflict resolver (optimistic approach).

I tested the conflict resolver but from my opinion, it is not working when different clients (ran in separate JVM) modify the same objet structuralFeatures : the conflict resolver is not correctly called when explained in this post : https://www.eclipse.org/forums/index.php?t=msg&th=854934&goto=1548077&#msg_1548077

I provided a project to show the bug nevertheless you can retrieve in this code how to set up a conflict resolver in your cdo transaction.

I did not get answer to my issue and I do hope CDO experts will answer me asap Very Happy

If you plan to use locks instead, have a look at CDOAutoLocker class but be careful, CDOAutoLocker class does not check if the modified object was already previously locked by itself (reentrance case).
In addition, you have to turn on the AutoReleasedLockEnabled properties in your transaction. This way, at each transaction commit / rollback, held locks are released.

Stéphane.




Re: [CDO] How to avoid LocalCommitConflictException [message #1554742 is a reply to message #1548090] Fri, 09 January 2015 11:29 Go to previous messageGo to next message
Phil Wim is currently offline Phil WimFriend
Messages: 89
Registered: October 2013
Member
Hi Stéphane,

thanks for your answer. Now I have a prove for my chosen approach. I use optimistic approach (conflict resolver). ConflictResolverTests pointed me out.

I haven't seen any conflicts since I added a conflict resolver to each CDOTransaction.

What would i need to o to implement the pessimistic approach? Do I have to lock the object explicit before i use Commands (Add/Remove) and release it after committing? Doesn't it happen implicit?

I will definitely take a look at CDOAutoLocker! Thanks for the tip.

To your problem, I have no experience with separate jvms, yet. Isn't conflict resolver working local? The other jvm doesn't know about the other CRs. But locking is on serverside. Die you try the pessimistic approach there?

Cheers
Phil

Re: [CDO] How to avoid LocalCommitConflictException [message #1557267 is a reply to message #1554742] Sat, 10 January 2015 21:29 Go to previous message
Stephane  Fournier is currently offline Stephane FournierFriend
Messages: 299
Registered: July 2009
Senior Member
Hi Phil,

If the optimistic approach is suitable for you use-case, it is better to use this approach. Indeed, locking objects is always complex if your client JVM crashes you can have remaining locked objects on server side, you have to deal with that situation.

In your use-case, do you have many transactions (or sessions) within the same JVM ?

To implement the pessimistic approach, you only have to add a CDOAutoLocker instance to your transaction. Automatically, the modified objects through your commands will be locked. Nevertheless, when I tested that, I had to extend the CDOAutoLocker to add a "if" statement : to check if the object to lock, is already locked by me or not. Without this test, when the transaction is committed (or rolled back), some locks on these objects remain. It happened when a same object was modified multiple times before committing the transaction --> multiple locks were held on the object instead of only one.

In addition, you can set some options on transaction / session to ask CDO to send lock notifications to other client if your need it.

Yes I'm currently evaluating both approaches. My preference would be the optimistic one for robustness (in case of crashes to avoid remaining locks) but I need to figure out this conflict resolver issue.

Stephane.

Phil Wim wrote on Fri, 09 January 2015 06:29
Hi Stéphane,

thanks for your answer. Now I have a prove for my chosen approach. I use optimistic approach (conflict resolver). ConflictResolverTests pointed me out.

I haven't seen any conflicts since I added a conflict resolver to each CDOTransaction.

What would i need to o to implement the pessimistic approach? Do I have to lock the object explicit before i use Commands (Add/Remove) and release it after committing? Doesn't it happen implicit?

I will definitely take a look at CDOAutoLocker! Thanks for the tip.

To your problem, I have no experience with separate jvms, yet. Isn't conflict resolver working local? The other jvm doesn't know about the other CRs. But locking is on serverside. Die you try the pessimistic approach there?

Cheers
Phil

Previous Topic:[CDO]Unable to resolve CDOClassifierRef error
Next Topic:AbstractEnumeratorExternalizeable; no valid constructor
Goto Forum:
  


Current Time: Sun Sep 15 14:21:44 GMT 2019

Powered by FUDForum. Page generated in 0.02160 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top