|Re: [CDO] How to avoid LocalCommitConflictException [message #1557267 is a reply to message #1554742]
||Sat, 10 January 2015 21:29
| Stephane Fournier
Registered: July 2009
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.
Phil Wim wrote on Fri, 09 January 2015 06:29
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?
Powered by FUDForum
. Page generated in 0.02865 seconds