Eclipse Community Forums: EMF » [CDO] How to avoid LocalCommitConflictException

Help

Home

Home » Modeling » EMF » [CDO] How to avoid LocalCommitConflictException

Show: Today's Messages :: Show Polls :: Message Navigator

[CDO] How to avoid LocalCommitConflictException [message #1497231]

Wed, 03 December 2014 17:04

Phil Wim

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

Report message to a moderator

Re: [CDO] How to avoid LocalCommitConflictException [message #1548090 is a reply to message #1497231]

Mon, 05 January 2015 20:54

Stephane fournier

Messages: 340
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.

Report message to a moderator

Re: [CDO] How to avoid LocalCommitConflictException [message #1554742 is a reply to message #1548090]

Fri, 09 January 2015 11:29

Phil Wim

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

Report message to a moderator

Re: [CDO] How to avoid LocalCommitConflictException [message #1557267 is a reply to message #1554742]

Sat, 10 January 2015 21:29

Stephane fournier

Messages: 340
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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu May 09 11:02:45 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter