Home » Modeling » EMF » [CDO] handling conflicts
| [CDO] handling conflicts [message #420980] |
Fri, 18 July 2008 18:02  |
 Tom Crockett
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi, I'm wondering what my options are for dealing with transactions in
conflict. Right now the only option I know of is to call
transaction.rollback(true), but this is undesirable for reasons I'll
outline.
Here's my use case:
2 users are modifying the same CDO resource concurrently. They are NOT
modifying the same objects within the resource, however, so technically
there is no conflict.
User 1 does this:
resource.getContents().add(object1);
User 2 does this:
resource.getContents().add(object2);
User 1 does this:
transaction.commit();
User 2 is listening to his resource and gets notified of an invalidate
event which puts it into conflict. He cannot commit his addition to the
resource (object2) without first bringing his transaction up-to-date.
However if he calls transaction.rollback(true), obviously he loses his new
object (object2) which he wanted to add.
What can I do about this? I've tried copying the transaction's newObjects
list prior to rolling back, then re-adding them, but the objects still
seem to be tainted with references to the old transaction; adding them to
the new transaction causes an exception on the server which in turn makes
the client hang forever :-/ (incidentally, this is another big problem,
the fact that the client can get into a state where it's waiting forever
for a response from the server which never comes, but that's a subject for
another post.)
So is rolling back not the right way to handle a conflict? What I really
want is the ability to merge the contents of my version of the resource
with what is on the server.
Tom
|
|
|
| Re: [CDO] handling conflicts [message #420981 is a reply to message #420980] |
Fri, 18 July 2008 18:31  |
|
Hi Thomas,
Comments below...
Thomas M Crockett schrieb:
> Hi, I'm wondering what my options are for dealing with transactions in
> conflict. Right now the only option I know of is to call
> transaction.rollback(true), but this is undesirable for reasons I'll
> outline.
>
> Here's my use case:
>
> 2 users are modifying the same CDO resource concurrently. They are NOT
> modifying the same objects within the resource, however, so
> technically there is no conflict.
They ARE modifying the same object: the resource through its contents
collection.
So there's a real conflict in a technical sense here.
> User 1 does this:
> resource.getContents().add(object1);
>
> User 2 does this:
>
> resource.getContents().add(object2);
>
> User 1 does this:
>
> transaction.commit();
>
> User 2 is listening to his resource and gets notified of an invalidate
> event which puts it into conflict. He cannot commit his addition to
> the resource (object2) without first bringing his transaction
> up-to-date. However if he calls transaction.rollback(true), obviously
> he loses his new object (object2) which he wanted to add.
>
> What can I do about this?
Since both transactions modified the same resource object rolling back
looks like the only approach.
> I've tried copying the transaction's newObjects list prior to rolling
> back, then re-adding them, but the objects still seem to be tainted
> with references to the old transaction; adding them to the new
> transaction causes an exception on the server ...
Unfortunately detach() is not yet implemented because it's not trivial
and I was always unsure how to define the requirements. At the time an
object is detached from its view/transaction it is not known if it will
be re-attached to the same view or a different one. If a different view
will be used it is for example necessary to assign the object a new
CDOID and mark it NEW. If the same view will be used the original CDOID
and DIRTY would be better.
See bug 204890: Implement detach
https://bugs.eclipse.org/bugs/show_bug.cgi?id=204890
Have you tried to copy the object state into a new object and attach
that after rollback?
> ... which in turn makes the client hang forever :-/ (incidentally,
> this is another big problem, the fact that the client can get into a
> state where it's waiting forever for a response from the server which
> never comes, but that's a subject for another post.)
How does your client look like?
Is it the CDO UI or does it use the CDO UI?
> So is rolling back not the right way to handle a conflict? What I
> really want is the ability to merge the contents of my version of the
> resource with what is on the server.
Understandeable but I feel like this is beyond the scope of what I can
develop.
Maybe an enhancement request for discussion and the will to participate
would be good.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] handling conflicts [message #420982 is a reply to message #420981] |
Fri, 18 July 2008 19:05 |
Tom Crockett
Messages: 54
Registered: July 2009 |
Member |
|
|
Eike Stepper wrote:
> Thomas M Crockett schrieb:
>> I've tried copying the transaction's newObjects list prior to rolling
>> back, then re-adding them, but the objects still seem to be tainted
>> with references to the old transaction; adding them to the new
>> transaction causes an exception on the server ...
> Unfortunately detach() is not yet implemented because it's not trivial
> and I was always unsure how to define the requirements. At the time an
> object is detached from its view/transaction it is not known if it will
> be re-attached to the same view or a different one. If a different view
> will be used it is for example necessary to assign the object a new
> CDOID and mark it NEW. If the same view will be used the original CDOID
> and DIRTY would be better.
As I said in the original post, *all* these objects I want to re-add are
NEW. In fact, this problem does not occur if client 2 is merely in the
middle of editing a dirty, persisted object, because the addition of
another object to the resource does not create a conflict! This is only a
problem when client 2 has added an object to the resource but not yet
saved it.
> See bug 204890: Implement detach
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204890
> Have you tried to copy the object state into a new object and attach
> that after rollback?
That was another approach I was considering, although it feels hacky and
will cause problems with my GEF editor maintaining the object's
selection... it would be preferable if I could "zero out" the fields in
the object which tie it to the life it knew prior to rollback. I guess
what I'm describing is a detach() method :)
>> ... which in turn makes the client hang forever :-/ (incidentally,
>> this is another big problem, the fact that the client can get into a
>> state where it's waiting forever for a response from the server which
>> never comes, but that's a subject for another post.)
> How does your client look like?
> Is it the CDO UI or does it use the CDO UI?
It's a GEF editor ;)
Tom
|
|
|
| Re: [CDO] handling conflicts [message #420985 is a reply to message #420982] |
Sat, 19 July 2008 06:11 |
|
Thomas M Crockett schrieb:
> Eike Stepper wrote:
>
>> Thomas M Crockett schrieb:
>
>>> I've tried copying the transaction's newObjects list prior to
>>> rolling back, then re-adding them, but the objects still seem to be
>>> tainted with references to the old transaction; adding them to the
>>> new transaction causes an exception on the server ...
>> Unfortunately detach() is not yet implemented because it's not
>> trivial and I was always unsure how to define the requirements. At
>> the time an object is detached from its view/transaction it is not
>> known if it will be re-attached to the same view or a different one.
>> If a different view will be used it is for example necessary to
>> assign the object a new CDOID and mark it NEW. If the same view will
>> be used the original CDOID and DIRTY would be better.
>
> As I said in the original post, *all* these objects I want to re-add
> are NEW.
Yes, I thought that. But more important than the cdoState is the cdoID
which must change if the object were to be re-attached to a different
view (at least if the views session points to a different repository).
> In fact, this problem does not occur if client 2 is merely in the
> middle of editing a dirty, persisted object, because the addition of
> another object to the resource does not create a conflict! This is
> only a problem when client 2 has added an object to the resource but
> not yet saved it.
Hmm, I'm not sure that I understand exactly this scenario. Do you think
it's possible to write a little test case against the test models
shipped with the SDK?
It's quite simple. Please have a look at the existing test cases,
particularly
>
>> See bug 204890: Implement detach
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204890
>
>> Have you tried to copy the object state into a new object and attach
>> that after rollback?
>
> That was another approach I was considering, although it feels hacky
> and will cause problems with my GEF editor maintaining the object's
> selection... it would be preferable if I could "zero out" the fields
> in the object which tie it to the life it knew prior to rollback. I
> guess what I'm describing is a detach() method :)
Although I don't think that a deep copy is hacky (consider that the
object could be re-attached to a different repository) I understand that
existing client frameworks don't like that very much. The detach()
request is already P1 and IIRC Simon told me it's on the top of his list.
>
>>> ... which in turn makes the client hang forever :-/ (incidentally,
>>> this is another big problem, the fact that the client can get into a
>>> state where it's waiting forever for a response from the server
>>> which never comes, but that's a subject for another post.)
>> How does your client look like?
>> Is it the CDO UI or does it use the CDO UI?
>
> It's a GEF editor ;)
Ok, I only asked because there is a subtle and rare sync problem between
the CDO core and CDO UI.
But then your problem looks more like a result from all read-access
request timeouts being set to NO_TIMEOUT.
Could you please drop me a Bugzilla so that I can add configurable
timeouts for *all* requests.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] handling conflicts [message #420989 is a reply to message #420985] |
Sat, 19 July 2008 19:03 |
Tom Crockett
Messages: 54
Registered: July 2009 |
Member |
|
|
Eike Stepper wrote:
> Thomas M Crockett schrieb:
>> Eike Stepper wrote:
>>
>>> Thomas M Crockett schrieb:
>>
>> As I said in the original post, *all* these objects I want to re-add
>> are NEW.
> Yes, I thought that. But more important than the cdoState is the cdoID
> which must change if the object were to be re-attached to a different
> view (at least if the views session points to a different repository).
In my particular case I'm reattaching to the same transaction after
calling transaction.rollback(true).
>> In fact, this problem does not occur if client 2 is merely in the
>> middle of editing a dirty, persisted object, because the addition of
>> another object to the resource does not create a conflict! This is
>> only a problem when client 2 has added an object to the resource but
>> not yet saved it.
> Hmm, I'm not sure that I understand exactly this scenario. Do you think
> it's possible to write a little test case against the test models
> shipped with the SDK?
> It's quite simple. Please have a look at the existing test cases,
> particularly
All I meant by this is that the resource becomes conflicted only if there
are NEW objects in it when it gets invalidated (correct me if I'm wrong.)
If instead a client is in the process of editing an object that has
already been persisted in the resource, they will not be put into conflict
by the addition of another object to the resource by a different client.
I'm not saying there's a bug here, this all makes sense to me.
>>
>>> See bug 204890: Implement detach
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204890
>>
>>> Have you tried to copy the object state into a new object and attach
>>> that after rollback?
>>
>> That was another approach I was considering, although it feels hacky
>> and will cause problems with my GEF editor maintaining the object's
>> selection... it would be preferable if I could "zero out" the fields
>> in the object which tie it to the life it knew prior to rollback. I
>> guess what I'm describing is a detach() method :)
> Although I don't think that a deep copy is hacky (consider that the
> object could be re-attached to a different repository) I understand that
> existing client frameworks don't like that very much. The detach()
> request is already P1 and IIRC Simon told me it's on the top of his list.
Cloning the NEW objects using EcoreUtil.copy() and adding the clones after
rolling back seems to work. It's still a pain because they are different
objects however, and the selection state of the viewer has to be reset, as
well as auxiliary views which reflect the selection of the viewer. I
eagerly await detach() if it allows me to keep the same objects and
reattach them after rollback.
>>
>>>> ... which in turn makes the client hang forever :-/ (incidentally,
>>>> this is another big problem, the fact that the client can get into a
>>>> state where it's waiting forever for a response from the server
>>>> which never comes, but that's a subject for another post.)
>>> How does your client look like?
>>> Is it the CDO UI or does it use the CDO UI?
>>
>> It's a GEF editor ;)
> Ok, I only asked because there is a subtle and rare sync problem between
> the CDO core and CDO UI.
> But then your problem looks more like a result from all read-access
> request timeouts being set to NO_TIMEOUT.
> Could you please drop me a Bugzilla so that I can add configurable
> timeouts for *all* requests.
Here's a bugzilla for customizable timeouts:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=241464
> Cheers
> /Eike
|
|
|
| Re: [CDO] handling conflicts [message #420990 is a reply to message #420989] |
Sat, 19 July 2008 19:24 |
|
Thomas M Crockett schrieb:
> [...]
>
>>> In fact, this problem does not occur if client 2 is merely in the
>>> middle of editing a dirty, persisted object, because the addition of
>>> another object to the resource does not create a conflict! This is
>>> only a problem when client 2 has added an object to the resource but
>>> not yet saved it.
>> Hmm, I'm not sure that I understand exactly this scenario. Do you
>> think it's possible to write a little test case against the test
>> models shipped with the SDK?
>> It's quite simple. Please have a look at the existing test cases,
>> particularly
>
> All I meant by this is that the resource becomes conflicted only if
> there are NEW objects in it when it gets invalidated (correct me if
> I'm wrong.) If instead a client is in the process of editing an object
> that has already been persisted in the resource, they will not be put
> into conflict by the addition of another object to the resource by a
> different client. I'm not saying there's a bug here, this all makes
> sense to me.
Ah, now I see. In the first case the resource object itself is DIRTY due
to modified contents list. in the second case only the modified
contained object is DIRTY and the containing resource stays CLEAN.
>>>> See bug 204890: Implement detach
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=204890
>>>
>>>> Have you tried to copy the object state into a new object and
>>>> attach that after rollback?
>>>
>>> That was another approach I was considering, although it feels hacky
>>> and will cause problems with my GEF editor maintaining the object's
>>> selection... it would be preferable if I could "zero out" the fields
>>> in the object which tie it to the life it knew prior to rollback. I
>>> guess what I'm describing is a detach() method :)
>> Although I don't think that a deep copy is hacky (consider that the
>> object could be re-attached to a different repository) I understand
>> that existing client frameworks don't like that very much. The
>> detach() request is already P1 and IIRC Simon told me it's on the top
>> of his list.
>
>
> Cloning the NEW objects using EcoreUtil.copy() and adding the clones
> after rolling back seems to work. It's still a pain because they are
> different objects however, and the selection state of the viewer has
> to be reset, as well as auxiliary views which reflect the selection of
> the viewer. I eagerly await detach() if it allows me to keep the same
> objects and reattach them after rollback.
I just started on that one but it will probably take some while because
it's really tricky.
I only started to think about what happens at server side if references
to the detached objects exist...
>>>>> ... which in turn makes the client hang forever :-/ (incidentally,
>>>>> this is another big problem, the fact that the client can get into
>>>>> a state where it's waiting forever for a response from the server
>>>>> which never comes, but that's a subject for another post.)
>>>> How does your client look like?
>>>> Is it the CDO UI or does it use the CDO UI?
>>>
>>> It's a GEF editor ;)
>> Ok, I only asked because there is a subtle and rare sync problem
>> between the CDO core and CDO UI.
>> But then your problem looks more like a result from all read-access
>> request timeouts being set to NO_TIMEOUT.
>> Could you please drop me a Bugzilla so that I can add configurable
>> timeouts for *all* requests.
>
>
> Here's a bugzilla for customizable timeouts:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=241464
This one should be easy and I'll start on it tomorrow.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Fri Apr 26 03:04:04 GMT 2024
Powered by FUDForum. Page generated in 0.03604 seconds |
] 
Search
Help
Register
Login
Home
