Eclipse Community Forums: EMF » [CDO] Update an historical revision with modification to an up-to-date and commitable revision

Home » Modeling » EMF » [CDO] Update an historical revision with modification to an up-to-date and commitable revision

[CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736755]

Fri, 01 July 2016 09:46

Eclipse User

Hello Eike,

I have a client with a scenario where two differents users add an element to the same container, one after the other. The container is locked by the first user adding an element until he commits. Then the second user adds his element and commits. This is a classic scenario, but strangely the second user commit is rejected because of a CommitConflictException: Attempt by Transaction[55:3] to modify historical revision. It looks like the invalidation (from the commit of the first user) has not reached the second user. Note that we were monitoring the VM status where the server is located and it was very busy (CPU and RAM).
An easy solution would be to force the second user to wait for this invalidation (not be allowed to modify an historical revision) but I am afraid that it will freeze Eclipse for too long.
Is it possible (and recommended) to force a refresh/invalidation of the cdoObject? I started to try the following way, but I am not sure if it is the right approach and if it is not too dangerous.
Map<CDOID, CDOObject> dirtyObjects = transaction.getDirtyObjects();
for (CDOObject cdoObject : dirtyObjects.values()) {
if(cdoObject.cdoRevision().isHistorical()) {
CDORevision lastRevision = transaction.getRevision(cdoObject.cdoID());
CDORevisionDelta delta = cdoObject.cdoRevision().compare(lastRevision);
CDOStateMachine.INSTANCE.invalidate((InternalCDOObject) cdoObject, delta);
}
}

Regards,
Steve

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736769 is a reply to message #1736755]

Fri, 01 July 2016 11:29

Eclipse User

Am 01.07.2016 um 15:46 schrieb Steve Monnier:
> Hello Eike,
>
> I have a client with a scenario where two differents users add an element to the same container, one after the other.
> The container is locked by the first user adding an element until he commits. Then the second user adds his element
> and commits. This is a classic scenario, but strangely the second user commit is rejected because of a
> CommitConflictException: Attempt by Transaction[55:3] to modify historical revision.
Did you add a CDOConflictResolver to the transaction of your second user?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

> It looks like the invalidation (from the commit of the first user) has not reached the second user. Note that we were
> monitoring the VM status where the server is located and it was very busy (CPU and RAM).
> An easy solution would be to force the second user to wait for this invalidation (not be allowed to modify an
> historical revision) but I am afraid that it will freeze Eclipse for too long.
> Is it possible (and recommended) to force a refresh/invalidation of the cdoObject? I started to try the following way,
> but I am not sure if it is the right approach and if it is not too dangerous.
> Map<CDOID, CDOObject> dirtyObjects = transaction.getDirtyObjects();
> for (CDOObject cdoObject : dirtyObjects.values()) {
> if(cdoObject.cdoRevision().isHistorical()) {
> CDORevision lastRevision = transaction.getRevision(cdoObject.cdoID());
> CDORevisionDelta delta = cdoObject.cdoRevision().compare(lastRevision);
> CDOStateMachine.INSTANCE.invalidate((InternalCDOObject) cdoObject, delta);
> }
> }
>
> Regards,
> Steve

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736901 is a reply to message #1736769]

Mon, 04 July 2016 05:41

Eclipse User

Hello Eike,

Thanks for your quick answer. Indeed, I have started to add a CDOConflictResolver on the second user but I have not tested so far. However I have my exception when the second user is trying to commit so I first guessed that the conflict resolver would not help as it is called on invalidation. Shouldn't I have an exception, before I try to commit, if the invalidation was missing a conflict resolver?

Regards,
Steve

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736905 is a reply to message #1736755]

Mon, 04 July 2016 06:15

Eclipse User

Am 01.07.2016 um 15:46 schrieb Steve Monnier:
> Hello Eike,
>
> I have a client with a scenario where two differents users add an element to the same container, one after the other.
> The container is locked by the first user adding an element until he commits. Then the second user adds his element
> and commits. This is a classic scenario, but strangely the second user commit is rejected because of a
> CommitConflictException: Attempt by Transaction[55:3] to modify historical revision.
Unless you use explicit locking you must always expect (and handle) commit conflicts. There can always be race
conditions over the wire.

> It looks like the invalidation (from the commit of the first user) has not reached the second user. Note that we were
> monitoring the VM status where the server is located and it was very busy (CPU and RAM).
That could mean that commit notifications are sent and received quite late.

> An easy solution would be to force the second user to wait for this invalidation (not be allowed to modify an
> historical revision) but I am afraid that it will freeze Eclipse for too long.
Not sure how you want to determine what to wait for.

> Is it possible (and recommended) to force a refresh/invalidation of the cdoObject?
No, typically you don't know what to wait for or whether more invalidations would come after.

> I started to try the following way, but I am not sure if it is the right approach and if it is not too dangerous.
> Map<CDOID, CDOObject> dirtyObjects = transaction.getDirtyObjects();
> for (CDOObject cdoObject : dirtyObjects.values()) {
> if(cdoObject.cdoRevision().isHistorical()) {
> CDORevision lastRevision = transaction.getRevision(cdoObject.cdoID());
> CDORevisionDelta delta = cdoObject.cdoRevision().compare(lastRevision);
> CDOStateMachine.INSTANCE.invalidate((InternalCDOObject) cdoObject, delta);
That's definitely very dangerous and not recommended. That's why CDOStateMachine is internal.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736906 is a reply to message #1736901]

Mon, 04 July 2016 06:17

Eclipse User

Am 04.07.2016 um 11:41 schrieb Steve Monnier:
> Hello Eike,
>
> Thanks for your quick answer. Indeed, I have started to add a CDOConflictResolver on the second user but I have not
> tested so far. However I have my exception when the second user is trying to commit so I first guessed that the
> conflict resolver would not help as it is called on invalidation. Shouldn't I have an exception, before I try to
> commit, if the invalidation was missing a conflict resolver?
No, a conflict resolver does normally not throw exceptions; they'd occur on commit.

Can you attach a test case so that I understand what exactly you're doing?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736935 is a reply to message #1736906]

Mon, 04 July 2016 08:33

Eclipse User

Yes we use an explicit locking mechanism, as soon as a element is modified, it is locked.

Unfurtunately I cannot attach a test case as the only way to reproduce the issue on my computer was to block the invalidation process.

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736944 is a reply to message #1736935]

Mon, 04 July 2016 10:02

Eclipse User

Am 04.07.2016 um 14:33 schrieb Steve Monnier:
> Yes we use an explicit locking mechanism, as soon as a element is modified, it is locked.
It is not possible to create a conflict on a locked object.

>
> Unfurtunately I cannot attach a test case as the only way to reproduce the issue on my computer was to block the
> invalidation process.
What do you mean by "block the invalidation process"?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1736961 is a reply to message #1736944]

Mon, 04 July 2016 12:19

Eclipse User

>> Yes we use an explicit locking mechanism, as soon as a element is modified, it is locked.
>It is not possible to create a conflict on a locked object.
Yes, that is why I think the user2 is modifying the element, after the unlock of the element but before the invalidation, both comming from user1 commit.

>> Unfurtunately I cannot attach a test case as the only way to reproduce the issue on my computer was to block the
>> invalidation process.
>What do you mean by "block the invalidation process"?
It is ugly but I avoid the process in CDOViewImpl.doInvalidate if this is concerning the element that is modified by bother user, in order to reproduce the issue on my computer.

In that case, when the second user modifies the element the revision is outdated. transaction.getRevision(cdoObject.cdoID()) returns a newer revision than cdoObject.cdoRevision(). Therefore on modification I am able to check if the element's revision is historical and wait until it is not, hoping it will be received soon.

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1737073 is a reply to message #1736961]

Tue, 05 July 2016 09:46

Eclipse User

As workaround, before user 2 modifies the elements I have added the following instructions:
if(element.cdoRevision().isHistorical()) {
((CDOObjectImpl)element).cdoInternalSetRevision(transaction.getRevision(element.cdoID()));
}
The revision of the element is replaced by the last one. There is no exception on commit because the CDORevisionDelta will be created using the last revision. User2 is only not aware of the element created by User1.

However I am afraid that the fact that isHistorical() and transaction.getRevision(element.cdoID()) return the up-to-date information only because avoiding the CDOViewImpl.doInvalidate process is different that in the real world where the notification is received too late. Is there a way to request directly to the server if a revision is historical and which version is the latest?

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1737145 is a reply to message #1736961]

Wed, 06 July 2016 02:46

Eclipse User

Am 04.07.2016 um 18:19 schrieb Steve Monnier:
>
>>> Yes we use an explicit locking mechanism, as soon as a element is modified, it is locked.
>> It is not possible to create a conflict on a locked object.
> Yes, that is why I think the user2 is modifying the element, after the unlock of the element but before the
> invalidation, both comming from user1 commit.
>
>
>>> Unfurtunately I cannot attach a test case as the only way to reproduce the issue on my computer was to block the
>>> invalidation process.
>> What do you mean by "block the invalidation process"?
> It is ugly but I avoid the process in CDOViewImpl.doInvalidate if this is concerning the element that is modified by
> bother user, in order to reproduce the issue on my computer.
I'm not sure why you're doing that, but it's clearly not recommended. Various problems can result from changing the
internal behaviour. And I can't give support for any such problems.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> In that case, when the second user modifies the element the revision is outdated.
> transaction.getRevision(cdoObject.cdoID()) returns a newer revision than cdoObject.cdoRevision(). Therefore on
> modification I am able to check if the element's revision is historical and wait until it is not, hoping it will be
> received soon.

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1737461 is a reply to message #1737145]

Fri, 08 July 2016 08:38

Eclipse User

Re: [CDO] Update an historical revision with modification to an up-to-date and commitable revision [message #1737468 is a reply to message #1737461]

Fri, 08 July 2016 09:11

Eclipse User

Steve,

Only with an explicit (read or write) lock you can ensure that you atomically get the latest revision of an object and
that nobody else can change the object anymore until you release the lock.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Am 08.07.2016 um 15:38 schrieb Steve Monnier:
> As workaround, before user 2 modifies the elements I have added the following instructions:
> if(element.cdoRevision().isHistorical()) {
> ((CDOObjectImpl)element).cdoInternalSetRevision(transaction.getRevision(element.cdoID()));
> }
> The revision of the element is replaced by the last one. There is no exception on commit because the CDORevisionDelta
> will be created using the last revision. User2 is only not aware of the element created by User1.
>
> However I am afraid that the fact that isHistorical() and transaction.getRevision(element.cdoID()) return the
> up-to-date information only because avoiding the CDOViewImpl.doInvalidate process is different that in the real world
> where the notification is received too late. Is there a way to request directly to the server if a revision is
> historical and which version is the latest?

Previous Topic:	Illegal State Exception with EMF Transaction
Next Topic:	[CDO] Commit memory footprint

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 13 14:01:04 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter