Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [CDO] how to handle object update conflicts
| [CDO] how to handle object update conflicts [message #100873] |
Tue, 06 November 2007 11:29  |
Eclipse User |
|
|
|
Eike,
I have the invalidation notifications working now. But now I need to be
able to handle the case where user A modifies an object, but does not
save, then user B modified and saves the same object. When user A
finally does a save he gets an error that says the version is a
duplicate, which makes sense.
How do I handle this case in my client with user A losing his work. Can
I refresh the objects so that he can save..?
Mark.
|
|
| |
| Re: [CDO] how to handle object update conflicts [message #101208 is a reply to message #101125] |
Wed, 07 November 2007 15:17  |
| Eclipse User |
|
|
|
Eike,
I have playing with the rollback for awhile now and I don't see what I
expect.
I have two clients running. In client #1 I modify an object but do not
save/commit. In client #2 I modify the same object and save. When the
save on client #2 occurs I receive an event CDOTransactionConflictEvent
in client #1. When I receive that event I do a rollback(true) and the
object reverts to the remote version PRIOR to the save on client #2, so
now the object looks like it did before ANY modifications. At this point
I can do more changes and saves in client #2 with no problem, but
nothing I do in client #1 will cause changes to be saved. It is as
though the object in client #1 is invalid for ever after the conflict.
So, how do I get the object in client #1 in a state that it can be
used...
Mark.
On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> Mark,
>
> There is a Rollback... entry on the transaction's context menu in the
> CDO Sessions view.
> I've just committed two changes:
>
> 1) CDOTransaction API has now a boolean remote parameter on the
> rollback() method.
> Remote rollback will rollback the transaction to reflect the latest
> *remote* state.
> Local rollback will rollback the transaction to reflect the latest
> *local* state. This is not dangerous but can lead to undesired local
> effects when the conflicting object is edited and committed later!
>
> 2) The RollbackTransactionDialog now appears after a version conflict is
> detected on save.
>
> I guess now it'smore obvious what to do ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
> > Eike,
> >
> > I have the invalidation notifications working now. But now I need to be
> > able to handle the case where user A modifies an object, but does not
> > save, then user B modified and saves the same object. When user A
> > finally does a save he gets an error that says the version is a
> > duplicate, which makes sense.
> >
> > How do I handle this case in my client with user A losing his work. Can
> > I refresh the objects so that he can save..?
> >
> > Mark.
> >
> >
|
|
|
| Re: [CDO] how to handle object update conflicts [message #101221 is a reply to message #101208] |
Wed, 07 November 2007 15:59 |
| Eclipse User |
|
|
|
Eike,
Some more information here may help.
The situation I need to handle is when, in production, two different
users modify large numbers of objects, say 10s or 100s over some
significant time. They may have a single object common to each users set
of modified objects. When they go to save what may be an hour of work
one of them, the last in this case, loses all their work. The database
is consistent, but there is loss of work. I need to be able to recover
the conflicted client to state that a save/commit will succeed.
Mark.
On Wed, 2007-11-07 at 13:17 -0700, Mark Geib wrote:
> Eike,
>
> I have playing with the rollback for awhile now and I don't see what I
> expect.
>
> I have two clients running. In client #1 I modify an object but do not
> save/commit. In client #2 I modify the same object and save. When the
> save on client #2 occurs I receive an event CDOTransactionConflictEvent
> in client #1. When I receive that event I do a rollback(true) and the
> object reverts to the remote version PRIOR to the save on client #2, so
> now the object looks like it did before ANY modifications. At this point
> I can do more changes and saves in client #2 with no problem, but
> nothing I do in client #1 will cause changes to be saved. It is as
> though the object in client #1 is invalid for ever after the conflict.
>
> So, how do I get the object in client #1 in a state that it can be
> used...
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> > Mark,
> >
> > There is a Rollback... entry on the transaction's context menu in the
> > CDO Sessions view.
> > I've just committed two changes:
> >
> > 1) CDOTransaction API has now a boolean remote parameter on the
> > rollback() method.
> > Remote rollback will rollback the transaction to reflect the latest
> > *remote* state.
> > Local rollback will rollback the transaction to reflect the latest
> > *local* state. This is not dangerous but can lead to undesired local
> > effects when the conflicting object is edited and committed later!
> >
> > 2) The RollbackTransactionDialog now appears after a version conflict is
> > detected on save.
> >
> > I guess now it'smore obvious what to do ;-)
> >
> > Regards,
> > Eike Stepper
> > ----
> > http://wiki.eclipse.org/?title=CDO
> > http://wiki.eclipse.org/?title=Net4j
> >
> >
> >
> > Mark Geib schrieb:
> > > Eike,
> > >
> > > I have the invalidation notifications working now. But now I need to be
> > > able to handle the case where user A modifies an object, but does not
> > > save, then user B modified and saves the same object. When user A
> > > finally does a save he gets an error that says the version is a
> > > duplicate, which makes sense.
> > >
> > > How do I handle this case in my client with user A losing his work. Can
> > > I refresh the objects so that he can save..?
> > >
> > > Mark.
> > >
> > >
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #101238 is a reply to message #101208] |
Wed, 07 November 2007 16:28 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------030700050005090001060008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mark Geib schrieb:
> Eike,
>
> I have playing with the rollback for awhile now and I don't see what I
> expect.
>
> I have two clients running. In client #1 I modify an object but do not
> save/commit. In client #2 I modify the same object and save. When the
> save on client #2 occurs I receive an event CDOTransactionConflictEvent
> in client #1. When I receive that event I do a rollback(true) and the
> object reverts to the remote version PRIOR to the save on client #2, so
> now the object looks like it did before ANY modifications.
That's not what happens here.
The conflicting object in client #1 reverts to the version client #2 has
committed.
Could you please try a CVS update.
Recently I experienced delays in the CVS mirrors.
May be you don't have the most recent version?!
If the misbehaviour persists I need to know more about your clients.
You don't use the CDOEditor?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
> At this point
> I can do more changes and saves in client #2 with no problem, but
> nothing I do in client #1 will cause changes to be saved. It is as
> though the object in client #1 is invalid for ever after the conflict.
>
> So, how do I get the object in client #1 in a state that it can be
> used...
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>
>> Mark,
>>
>> There is a Rollback... entry on the transaction's context menu in the
>> CDO Sessions view.
>> I've just committed two changes:
>>
>> 1) CDOTransaction API has now a boolean remote parameter on the
>> rollback() method.
>> Remote rollback will rollback the transaction to reflect the latest
>> *remote* state.
>> Local rollback will rollback the transaction to reflect the latest
>> *local* state. This is not dangerous but can lead to undesired local
>> effects when the conflicting object is edited and committed later!
>>
>> 2) The RollbackTransactionDialog now appears after a version conflict is
>> detected on save.
>>
>> I guess now it'smore obvious what to do ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have the invalidation notifications working now. But now I need to be
>>> able to handle the case where user A modifies an object, but does not
>>> save, then user B modified and saves the same object. When user A
>>> finally does a save he gets an error that says the version is a
>>> duplicate, which makes sense.
>>>
>>> How do I handle this case in my client with user A losing his work. Can
>>> I refresh the objects so that he can save..?
>>>
>>> Mark.
>>>
>>>
>>>
>
>
--------------030700050005090001060008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark Geib schrieb:
<blockquote cite="mid:1194466661.883.6.camel@dhcp07-gr.dev.uplink"
type="cite">
<pre wrap="">Eike,
I have playing with the rollback for awhile now and I don't see what I
expect.
I have two clients running. In client #1 I modify an object but do not
save/commit. In client #2 I modify the same object and save. When the
save on client #2 occurs I receive an event CDOTransactionConflictEvent
in client #1. When I receive that event I do a rollback(true) and the
object reverts to the remote version PRIOR to the save on client #2, so
now the object looks like it did before ANY modifications. </pre>
</blockquote>
That's not what happens here.<br>
The conflicting object in client #1 reverts to the version client #2
has committed.<br>
<br>
Could you please try a CVS update. <br>
Recently I experienced delays in the CVS mirrors. <br>
May be you don't have the most recent version?!<br>
<br>
If the misbehaviour persists I need to know more about your clients.<br>
You don't use the CDOEditor?<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=CDO">http://wiki.eclipse.org/?title=CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=Net4j">http://wiki.eclipse.org/?title=Net4j</a><br>
<br>
<br>
<blockquote cite="mid:1194466661.883.6.camel@dhcp07-gr.dev.uplink"
type="cite">
<pre wrap="">At this point
I can do more changes and saves in client #2 with no problem, but
nothing I do in client #1 will cause changes to be saved. It is as
though the object in client #1 is invalid for ever after the conflict.
So, how do I get the object in client #1 in a state that it can be
used...
Mark.
On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mark,
There is a Rollback... entry on the transaction's context menu in the
CDO Sessions view.
I've just committed two changes:
1) CDOTransaction API has now a boolean remote parameter on the
rollback() method.
Remote rollback will rollback the transaction to reflect the latest
*remote* state.
Local rollback will rollback the transaction to reflect the latest
*local* state. This is not dangerous but can lead to undesired local
effects when the conflicting object is edited and committed later!
2) The RollbackTransactionDialog now appears after a version conflict is
detected on save.
I guess now it'smore obvious what to do ;-)
Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=CDO">http://wiki.eclipse.org/?title=CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=Net4j">http://wiki.eclipse.org/?title=Net4j</a>
Mark Geib schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Eike,
I have the invalidation notifications working now. But now I need to be
able to handle the case where user A modifies an object, but does not
save, then user B modified and saves the same object. When user A
finally does a save he gets an error that says the version is a
duplicate, which makes sense.
How do I handle this case in my client with user A losing his work. Can
I refresh the objects so that he can save..?
Mark.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------030700050005090001060008--
|
|
|
| Re: [CDO] how to handle object update conflicts [message #101247 is a reply to message #101238] |
Wed, 07 November 2007 16:34 |
| Eclipse User |
|
|
|
Eike,
In my handler for the CDOTransactionConflictEvent event I call
transaction.rollback(true) and I get the version of the object prior to
any changes. If I call
CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
I don't use the CDOEditor at all. I could for testing, but my client is
very graphical, and in fact some of the objects in my model are the
graphical locations of the objects as well as the links between objects.
The use a tree based editor is fairly limited for my model.
Mark.
On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
> Mark Geib schrieb:
> > Eike,
> >
> > I have playing with the rollback for awhile now and I don't see what I
> > expect.
> >
> > I have two clients running. In client #1 I modify an object but do not
> > save/commit. In client #2 I modify the same object and save. When the
> > save on client #2 occurs I receive an event CDOTransactionConflictEvent
> > in client #1. When I receive that event I do a rollback(true) and the
> > object reverts to the remote version PRIOR to the save on client #2, so
> > now the object looks like it did before ANY modifications.
> That's not what happens here.
> The conflicting object in client #1 reverts to the version client #2
> has committed.
>
> Could you please try a CVS update.
> Recently I experienced delays in the CVS mirrors.
> May be you don't have the most recent version?!
>
> If the misbehaviour persists I need to know more about your clients.
> You don't use the CDOEditor?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> > At this point
> > I can do more changes and saves in client #2 with no problem, but
> > nothing I do in client #1 will cause changes to be saved. It is as
> > though the object in client #1 is invalid for ever after the conflict.
> >
> > So, how do I get the object in client #1 in a state that it can be
> > used...
> >
> > Mark.
> >
> >
> >
> > On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> >
> > > Mark,
> > >
> > > There is a Rollback... entry on the transaction's context menu in the
> > > CDO Sessions view.
> > > I've just committed two changes:
> > >
> > > 1) CDOTransaction API has now a boolean remote parameter on the
> > > rollback() method.
> > > Remote rollback will rollback the transaction to reflect the latest
> > > *remote* state.
> > > Local rollback will rollback the transaction to reflect the latest
> > > *local* state. This is not dangerous but can lead to undesired local
> > > effects when the conflicting object is edited and committed later!
> > >
> > > 2) The RollbackTransactionDialog now appears after a version conflict is
> > > detected on save.
> > >
> > > I guess now it'smore obvious what to do ;-)
> > >
> > > Regards,
> > > Eike Stepper
> > > ----
> > > http://wiki.eclipse.org/?title=CDO
> > > http://wiki.eclipse.org/?title=Net4j
> > >
> > >
> > >
> > > Mark Geib schrieb:
> > >
> > > > Eike,
> > > >
> > > > I have the invalidation notifications working now. But now I need to be
> > > > able to handle the case where user A modifies an object, but does not
> > > > save, then user B modified and saves the same object. When user A
> > > > finally does a save he gets an error that says the version is a
> > > > duplicate, which makes sense.
> > > >
> > > > How do I handle this case in my client with user A losing his work. Can
> > > > I refresh the objects so that he can save..?
> > > >
> > > > Mark.
> > > >
> > > >
> > > >
> >
> >
|
|
|
| Re: [CDO] how to handle object update conflicts [message #101290 is a reply to message #101247] |
Thu, 08 November 2007 02:33 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark Geib schrieb:
> Eike,
>
> In my handler for the CDOTransactionConflictEvent event I call
> transaction.rollback(true) and I get the version of the object prior to
> any changes. If I call
> CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
>
Some comments on the state machine call:
1) It should work but it is internal API. I'm currently working on a
public CDOObject.cdoRefresh(boolean force). Until then it you should
achieve the same effect (without force) by calling any non-transient
getter on the object.
2) The server stops to commit the transaction on the first conflict, so
the event possibly doesn't contain all conflicting objects. Rolling back
the client transaction to remote state in fact turns all modified
objects into proxies. the next access (if any) will reload the object
from the server.
I tested once more here and everything is working as expected.
Particularly the scenario you describe:
client1: open session
client1: register model
client1: open transaction
client1: create resource
client1: add object X
client1: save
client2: open session
client2: open transaction
client2: load resource
client2: modify object X.name = "B"
client1: modify object X.name = "A"
client1: save
client2: shows conflict on object X
client2: save
client2: opens transaction error dialog
client2: rollback to remote state
client2: show object X.name = "A"
client2: modify object X.name = "C"
client2: save
client2: show object X.name = "C"
client1: show object X.name = "C"
> I don't use the CDOEditor at all. I could for testing, but my client is
> very graphical, and in fact some of the objects in my model are the
> graphical locations of the objects as well as the links between objects.
> The use a tree based editor is fairly limited for my model.
>
Sounds interesting!
The specified ehaviour should of course be independent of the client
application, be it a UI or a batch.
I'll provide a standalone test case so that you can better compare with
your scenario...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
> Mark.
>
>
>
> On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have playing with the rollback for awhile now and I don't see what I
>>> expect.
>>>
>>> I have two clients running. In client #1 I modify an object but do not
>>> save/commit. In client #2 I modify the same object and save. When the
>>> save on client #2 occurs I receive an event CDOTransactionConflictEvent
>>> in client #1. When I receive that event I do a rollback(true) and the
>>> object reverts to the remote version PRIOR to the save on client #2, so
>>> now the object looks like it did before ANY modifications.
>>>
>> That's not what happens here.
>> The conflicting object in client #1 reverts to the version client #2
>> has committed.
>>
>> Could you please try a CVS update.
>> Recently I experienced delays in the CVS mirrors.
>> May be you don't have the most recent version?!
>>
>> If the misbehaviour persists I need to know more about your clients.
>> You don't use the CDOEditor?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>> At this point
>>> I can do more changes and saves in client #2 with no problem, but
>>> nothing I do in client #1 will cause changes to be saved. It is as
>>> though the object in client #1 is invalid for ever after the conflict.
>>>
>>> So, how do I get the object in client #1 in a state that it can be
>>> used...
>>>
>>> Mark.
>>>
>>>
>>>
>>> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>>>
>>>
>>>> Mark,
>>>>
>>>> There is a Rollback... entry on the transaction's context menu in the
>>>> CDO Sessions view.
>>>> I've just committed two changes:
>>>>
>>>> 1) CDOTransaction API has now a boolean remote parameter on the
>>>> rollback() method.
>>>> Remote rollback will rollback the transaction to reflect the latest
>>>> *remote* state.
>>>> Local rollback will rollback the transaction to reflect the latest
>>>> *local* state. This is not dangerous but can lead to undesired local
>>>> effects when the conflicting object is edited and committed later!
>>>>
>>>> 2) The RollbackTransactionDialog now appears after a version conflict is
>>>> detected on save.
>>>>
>>>> I guess now it'smore obvious what to do ;-)
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>
>>>>
>>>>> Eike,
>>>>>
>>>>> I have the invalidation notifications working now. But now I need to be
>>>>> able to handle the case where user A modifies an object, but does not
>>>>> save, then user B modified and saves the same object. When user A
>>>>> finally does a save he gets an error that says the version is a
>>>>> duplicate, which makes sense.
>>>>>
>>>>> How do I handle this case in my client with user A losing his work. Can
>>>>> I refresh the objects so that he can save..?
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #101933 is a reply to message #101247] |
Thu, 08 November 2007 03:17 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
This is a multi-part message in MIME format.
--------------090901010402030505080407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mark,
With the following test case (update cdo and cdo.tests) I can proof that
it's working standalone.
The flow1() method mimics exactly the same flow that I described in the
other reply.
The log output of the tests is attached.
public class RollbackTest extends AbstractCDOTest
{
public void testRollbackSameSession() throws Exception
{
CDOSession session = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session.getPackageRegistry().putEPackage(Model1Package.eINST ANCE);
CDOTransaction transaction1 = session.openTransaction();
CDOTransaction transaction2 = session.openTransaction();
flow1(transaction1, transaction2);
}
public void testRollbackSeparateSession() throws Exception
{
// Client1
CDOSession session1 = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session1.getPackageRegistry().putEPackage(Model1Package.eINS TANCE);
CDOTransaction transaction1 = session1.openTransaction();
// Client2
CDOSession session2 = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session2.getPackageRegistry().putEPackage(Model1Package.eINS TANCE);
CDOTransaction transaction2 = session2.openTransaction();
flow1(transaction1, transaction2);
}
protected void flow1(CDOTransaction transaction1, CDOTransaction
transaction2)
{
// Client1
CDOResource resource1 = transaction1.createResource("/test1");
Company company1 = Model1Factory.eINSTANCE.createCompany();
resource1.getContents().add(company1);
Category category1 = Model1Factory.eINSTANCE.createCategory();
company1.getCategories().add(category1);
transaction1.commit();
// Client2
CDOResource resource2 = transaction2.getResource("/test1");
Company company2 = (Company)resource2.getContents().get(0);
Category category2 = company2.getCategories().get(0);
category2.setName("client2");
// Client1
category1.setName("client1");
transaction1.commit();
sleep(500);
// Client2
assertEquals(true, transaction2.isDirty());
assertEquals(true, transaction2.hasConflict());
try
{
transaction2.commit();
fail("Commit on transaction2 should fail");
}
catch (TransactionException ex)
{
transaction2.rollback(true);
}
assertEquals(false, transaction2.isDirty());
assertEquals(false, transaction2.hasConflict());
assertEquals("client1", category2.getName());
category2.setName("client2");
transaction2.commit();
assertEquals(false, transaction2.isDirty());
assertEquals(false, transaction2.hasConflict());
assertEquals("client2", category2.getName());
sleep(500);
// Client1
assertEquals(false, transaction1.isDirty());
assertEquals(false, transaction1.hasConflict());
assertEquals("client2", category1.getName());
}
}
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> In my handler for the CDOTransactionConflictEvent event I call
> transaction.rollback(true) and I get the version of the object prior to
> any changes. If I call
> CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
>
> I don't use the CDOEditor at all. I could for testing, but my client is
> very graphical, and in fact some of the objects in my model are the
> graphical locations of the objects as well as the links between objects.
> The use a tree based editor is fairly limited for my model.
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have playing with the rollback for awhile now and I don't see what I
>>> expect.
>>>
>>> I have two clients running. In client #1 I modify an object but do not
>>> save/commit. In client #2 I modify the same object and save. When the
>>> save on client #2 occurs I receive an event CDOTransactionConflictEvent
>>> in client #1. When I receive that event I do a rollback(true) and the
>>> object reverts to the remote version PRIOR to the save on client #2, so
>>> now the object looks like it did before ANY modifications.
>>>
>> That's not what happens here.
>> The conflicting object in client #1 reverts to the version client #2
>> has committed.
>>
>> Could you please try a CVS update.
>> Recently I experienced delays in the CVS mirrors.
>> May be you don't have the most recent version?!
>>
>> If the misbehaviour persists I need to know more about your clients.
>> You don't use the CDOEditor?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>> At this point
>>> I can do more changes and saves in client #2 with no problem, but
>>> nothing I do in client #1 will cause changes to be saved. It is as
>>> though the object in client #1 is invalid for ever after the conflict.
>>>
>>> So, how do I get the object in client #1 in a state that it can be
>>> used...
>>>
>>> Mark.
>>>
>>>
>>>
>>> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>>>
>>>
>>>> Mark,
>>>>
>>>> There is a Rollback... entry on the transaction's context menu in the
>>>> CDO Sessions view.
>>>> I've just committed two changes:
>>>>
>>>> 1) CDOTransaction API has now a boolean remote parameter on the
>>>> rollback() method.
>>>> Remote rollback will rollback the transaction to reflect the latest
>>>> *remote* state.
>>>> Local rollback will rollback the transaction to reflect the latest
>>>> *local* state. This is not dangerous but can lead to undesired local
>>>> effects when the conflicting object is edited and committed later!
>>>>
>>>> 2) The RollbackTransactionDialog now appears after a version conflict is
>>>> detected on save.
>>>>
>>>> I guess now it'smore obvious what to do ;-)
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>
>>>>
>>>>> Eike,
>>>>>
>>>>> I have the invalidation notifications working now. But now I need to be
>>>>> able to handle the case where user A modifies an object, but does not
>>>>> save, then user B modified and saves the same object. When user A
>>>>> finally does a save he gets an error that says the version is a
>>>>> duplicate, which makes sense.
>>>>>
>>>>> How do I handle this case in my client with user A losing his work. Can
>>>>> I refresh the objects so that he can save..?
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--------------090901010402030505080407
Content-Type: text/x-log;
name="rollback.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="rollback.log"
************************************************
testRollbackSameSession
************************************************
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=3Dnull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRan=
ge=3Dnull)
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, metaIDRange=3Dn=
ull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOResource)
main [CDOFeatureImpl] Created CDOFeature(ID=3D8, name=3Dpath, type=3DSTRI=
NG, referenceType=3Dnull)
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D8, name=3Dpath, type=3D=
STRING, referenceType=3Dnull)
main [CDOFeatureImpl] Created CDOFeature(ID=3D2, name=3Dcontents, type=3D=
OBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D2, name=3Dcontents, t=
ype=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOResource)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, m=
etaIDRange=3Dnull)
main [Lifecycle] Activating Repository[repo1, null]
main [Lifecycle] Activating NOOPStore@1
main [Lifecycle] DUMP NOOPStore@1
Store.type =3D noop
Store.repository =3D Repository[repo1, null]
Store.nextOIDValue =3D 2
main [Lifecycle] Activating TypeManager@2
main [Lifecycle] DUMP TypeManager@2
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@1be0f0a[C=
ount =3D 0]
Worker.workerThread =3D Thread[Thread-0,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
repository =3D Repository[repo1, null]
persistent =3D false
objectTypes =3D=20
packageURIMap =3D null
packageIDMap =3D null
objectTypeMap =3D null
metaObjectTypeMap =3D null
nextPackageID =3D 0
main [Lifecycle] Activating PackageManager@3
main [Lifecycle] DUMP PackageManager@3
CDOPackageManagerImpl.packages =3D=20
http://www.eclipse.org/emf/CDO/core/1.0.0=3DCDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull)
http://www.eclipse.org/emf/CDO/resource/1.0.0=3DCDOPackage(URI=3Dhttp=
://www.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3D=
false, metaIDRange=3Dnull)
CDOPackageManagerImpl.cdoCorePackage =3D CDOPackage(URI=3Dhttp://www.ecl=
ipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=
=3Dnull)
CDOPackageManagerImpl.cdoResourcePackage =3D CDOPackage(URI=3Dhttp://www=
=2Eeclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull)
repository =3D Repository[repo1, null]
main [Lifecycle] Activating SessionManager@4
main [Lifecycle] DUMP SessionManager@4
repository =3D Repository[repo1, null]
sessions =3D=20
lastSessionID =3D 0
main [Lifecycle] Activating ResourceManager@5
main [Lifecycle] DUMP ResourceManager@5
repository =3D Repository[repo1, null]
idToPathMap =3D=20
pathToIDMap =3D=20
main [Lifecycle] Activating RevisionManager@6
main [Lifecycle] DUMP RevisionManager@6
CDORevisionResolverImpl.revisions =3D=20
CDORevisionResolverImpl.currentLRUCapacity =3D 0
CDORevisionResolverImpl.revisedLRUCapacity =3D 0
CDORevisionResolverImpl.currentLRU =3D LRU[size=3D0, capacity=3D0]
CDORevisionResolverImpl.revisedLRU =3D LRU[size=3D0, capacity=3D0]
repository =3D Repository[repo1, null]
cdoPathFeature =3D CDOFeature(ID=3D8, name=3Dpath, type=3DSTRING, refere=
nceType=3Dnull)
main [Lifecycle] DUMP Repository@7
name =3D repo1
store =3D NOOPStore@1
uuid =3D null
properties =3D=20
supportingAudits =3D false
verifyingRevisions =3D null
rememberingKnownTypes =3D null
typeManager =3D TypeManager@2
packageManager =3D PackageManager@3
sessionManager =3D SessionManager@4
resourceManager =3D ResourceManager@5
revisionManager =3D RevisionManager@6
elements =3D [Lorg.eclipse.emf.cdo.server.IRepositoryElement;@1275d39
nextMetaIDValue =3D 1
main [Lifecycle] Activating ManagedContainer
main [Lifecycle] Activating {org.eclipse.net4j.connectors[tcp]=3DFactory[=
org.eclipse.net4j.connectors, tcp], org.eclipse.net4j.randomizers[default=
]=3DFactory[org.eclipse.net4j.randomizers, default], org.eclipse.net4j.cl=
ientProtocols[cdo]=3DFactory[org.eclipse.net4j.clientProtoco ls, cdo], org=
=2Eeclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j. selectors, tc=
p], org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default], org.eclipse.net4j.acceptors[tcp]=3DFactory[o=
rg.eclipse.net4j.acceptors, tcp], org.eclipse.net4j.serverProtocols[cdo]=3D=
Factory[org.eclipse.net4j.serverProtocols, cdo], org.eclipse.net4j.execut=
orServices[default]=3DFactory[org.eclipse.net4j.executorServ ices, default=
]}
main [Lifecycle] DUMP HashMapRegistry@8
Registry.autoCommit =3D true
Registry.transaction =3D null
map =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
main [Lifecycle] DUMP ManagedContainer@9
factoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
postProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
elementRegistry =3D=20
org.eclipse.emf.cdo.server.repositories[default, repo1]=3DRepository[=
repo1, null]
maxElementID =3D 1
elementListener =3D org.eclipse.net4j.internal.util.container.ManagedCon=
tainer$1@25d2b2
main [Lifecycle] Activating BufferPool[4.096]
BufferPoolMonitor [BufferPool] Start monitoring
main [Lifecycle] DUMP BufferPool@10
BufferProvider.bufferCapacity =3D 4096
BufferProvider.providedBuffers =3D 0
BufferProvider.retainedBuffers =3D 0
provider =3D BufferFactory[4.096]
pooledBuffers =3D 0
main [Lifecycle] Activating TCPSelector
main [Lifecycle] DUMP TCPSelector@11
selector =3D sun.nio.ch.WindowsSelectorImpl@1175422
clientOperations =3D=20
serverOperations =3D=20
thread =3D Thread[TCPSelector,5,main]
running =3D true
main [Lifecycle] Activating TCPAcceptor[0.0.0.0:2.036]
main [TCPSelector] Ordering server operation REGISTER sun.nio.ch.ServerSo=
cketChannelImpl[unbound]
TCPSelector [TCPSelector] Executing server operation REGISTER sun.nio.ch.=
ServerSocketChannelImpl[unbound]
TCPSelector [TCPSelector] Registering sun.nio.ch.ServerSocketChannelImpl[=
unbound]
main [Lifecycle] DUMP TCPAcceptor@12
Acceptor.negotiator =3D null
Acceptor.bufferProvider =3D BufferPool[4.096]
Acceptor.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Acceptor.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Acceptor.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8=
e1e
Acceptor.lifecycleEventConverter =3D org.eclipse.internal.net4j.Acceptor=
$1@11671b2
Acceptor.acceptedConnectors =3D=20
selector =3D TCPSelector
selectionKey =3D sun.nio.ch.SelectionKeyImpl@4aa0ce
startSynchronously =3D true
synchronousStartTimeout =3D 4000
startLatch =3D java.util.concurrent.CountDownLatch@12452e8[Count =3D 0]
serverSocketChannel =3D sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036=
]
address =3D 0.0.0.0
port =3D 2036
main [Connector] Setting userID null for {2}
main [Lifecycle] Activating ClientTCPConnector[localhost:2.036]
main [Connector] Setting state CONNECTING (was disconnected) for ClientTC=
PConnector[localhost:2.036]
main [Lifecycle] Activating Channel[Control]
main [Lifecycle] Activating QueueWorkerWorkSerializer@13
main [Lifecycle] DUMP QueueWorkerWorkSerializer@13
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@961dff[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-2,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
main [Lifecycle] DUMP ControlChannel@14
Channel.channelID =3D 0
Channel.channelIndex =3D -1
Channel.connector =3D ClientTCPConnector[localhost:2.036]
Channel.receiveHandler =3D null
Channel.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e=
1e
Channel.receiveSerializer =3D QueueWorkerWorkSerializer@13
Channel.sendQueue =3D=20
registrations =3D SynchronizingCorrelator{}
main [TCPSelector] Ordering client operation REGISTER java.nio.channels.S=
ocketChannel[unconnected]
------------------------ START ------------------------
TCPSelector [TCPSelector] Executing client operation REGISTER java.nio.ch=
annels.SocketChannel[unconnected]
TCPSelector [TCPSelector] Registering java.nio.channels.SocketChannel[unc=
onnected]
TCPSelector [TCPSelector] Connecting java.nio.channels.SocketChannel[conn=
ection-pending remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [TCPSelector] Ordering client operation INTEREST CONNECT java=
=2Enio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3D=
localhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Ordering client operation INTEREST READ java.ni=
o.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocal=
host/127.0.0.1:2036] =3D true
TCPSelector [Connector] Setting state CONNECTED (was connecting) for Clie=
ntTCPConnector[localhost:2.036]
TCPSelector [Lifecycle] DUMP TCPClientConnector@15
Connector.userID =3D null
Connector.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Connector.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Connector.negotiator =3D null
Connector.negotiationContext =3D null
Connector.bufferProvider =3D BufferPool[4.096]
Connector.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc=
8e1e
Connector.nextChannelID =3D 1
Connector.channels =3D=20
Connector.channelsLock =3D org.eclipse.net4j.util.concurrent.RWLock@f8f7=
db[Write locks =3D 0, Read locks =3D 0]
Connector.connectorState =3D CONNECTED
Connector.channelListener =3D org.eclipse.internal.net4j.Connector$1@158=
56a5
Connector.finishedConnecting =3D java.util.concurrent.CountDownLatch@a08=
4f8[Count =3D 1]
Connector.finishedNegotiating =3D java.util.concurrent.CountDownLatch@79=
ed7f[Count =3D 1]
TCPConnector.socketChannel =3D java.nio.channels.SocketChannel[connected=
local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPConnector.selector =3D TCPSelector
TCPConnector.selectionKey =3D sun.nio.ch.SelectionKeyImpl@ac6a45
TCPConnector.inputBuffer =3D null
TCPConnector.controlChannel =3D Channel[Control]
TCPConnector.host =3D localhost
TCPConnector.port =3D 2036
TCPSelector [TCPSelector] Accepting sun.nio.ch.ServerSocketChannelImpl[/0=
=2E0.0.0:2036]
TCPSelector [TCPAcceptor] Accepted socketChannel java.nio.channels.Socket=
Channel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Lifecycle] Activating ServerTCPConnector[127.0.0.1:4.641]
TCPSelector [Connector] Setting state CONNECTING (was disconnected) for S=
erverTCPConnector[127.0.0.1:4.641]
TCPSelector [Lifecycle] Activating Channel[Control]
TCPSelector [Lifecycle] Activating QueueWorkerWorkSerializer@16
TCPSelector [Lifecycle] DUMP QueueWorkerWorkSerializer@16
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@13ad33d[C=
ount =3D 0]
Worker.workerThread =3D Thread[Thread-3,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
TCPSelector [Lifecycle] DUMP ControlChannel@17
Channel.channelID =3D 0
Channel.channelIndex =3D -1
Channel.connector =3D ServerTCPConnector[127.0.0.1:4.641]
Channel.receiveHandler =3D null
Channel.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e=
1e
Channel.receiveSerializer =3D QueueWorkerWorkSerializer@16
Channel.sendQueue =3D=20
registrations =3D SynchronizingCorrelator{}
TCPSelector [TCPSelector] Ordering server operation REGISTER java.nio.cha=
nnels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1=
:4641]
TCPSelector [TCPSelector] Executing server operation REGISTER java.nio.ch=
annels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.=
1:4641]
TCPSelector [TCPSelector] Registering java.nio.channels.SocketChannel[con=
nected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Connector] Setting state CONNECTED (was connecting) for Serv=
erTCPConnector[127.0.0.1:4.641]
TCPSelector [Lifecycle] DUMP TCPServerConnector@18
Connector.userID =3D null
Connector.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Connector.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Connector.negotiator =3D null
Connector.negotiationContext =3D null
Connector.bufferProvider =3D BufferPool[4.096]
Connector.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc=
8e1e
Connector.nextChannelID =3D 1
Connector.channels =3D=20
Connector.channelsLock =3D org.eclipse.net4j.util.concurrent.RWLock@1aed=
5f9[Write locks =3D 0, Read locks =3D 0]
Connector.connectorState =3D CONNECTED
Connector.channelListener =3D org.eclipse.internal.net4j.Connector$1@161=
dfb5
Connector.finishedConnecting =3D java.util.concurrent.CountDownLatch@a61=
3f8[Count =3D 1]
Connector.finishedNegotiating =3D java.util.concurrent.CountDownLatch@16=
921fd[Count =3D 1]
TCPConnector.socketChannel =3D java.nio.channels.SocketChannel[connected=
local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPConnector.selector =3D TCPSelector
TCPConnector.selectionKey =3D sun.nio.ch.SelectionKeyImpl@1d6f122
TCPConnector.inputBuffer =3D null
TCPConnector.controlChannel =3D Channel[Control]
TCPConnector.host =3D null
TCPConnector.port =3D 0
acceptor =3D TCPAcceptor[0.0.0.0:2.036]
TCPSelector [Acceptor] Added connector ServerTCPConnector[127.0.0.1:4.641=
]
TCPSelector [TCPSelector] Executing client operation INTEREST CONNECT jav=
a.nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dl=
ocalhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest (was connect)
TCPSelector [TCPSelector] Executing client operation INTEREST READ java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=3Dnull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRan=
ge=3Dnull)
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, metaIDRange=3Dn=
ull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOResource)
main [CDOFeatureImpl] Created CDOFeature(ID=3D8, name=3Dpath, type=3DSTRI=
NG, referenceType=3Dnull)
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D8, name=3Dpath, type=3D=
STRING, referenceType=3Dnull)
main [CDOFeatureImpl] Created CDOFeature(ID=3D2, name=3Dcontents, type=3D=
OBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D2, name=3Dcontents, t=
ype=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOResource)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, m=
etaIDRange=3Dnull)
main [CDOModelElementImpl] Setting client info: CDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull) --> org.eclipse.emf.ecore.impl.EcorePackageImpl@6fa9fc (na=
me: ecore) (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore=
)
main [CDOModelElementImpl] Setting client info: CDOClass(ID=3D0, name=3DC=
DOObject) --> org.eclipse.emf.ecore.impl.EClassImpl@3ae941 (name: EObject=
) (instanceClassName: null) (abstract: false, interface: false)
main [CDOModelElementImpl] Setting client info: CDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull) --> org.eclipse.emf.cdo.eresource.impl.EresourcePa=
ckageImpl@4ee70b (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO=
/resource/1.0.0, nsPrefix: eresource)
main [CDOModelElementImpl] Setting client info: CDOClass(ID=3D0, name=3DC=
DOResource) --> org.eclipse.emf.ecore.impl.EClassImpl@55a338 (name: CDORe=
source) (instanceClassName: null) (abstract: false, interface: false)
main [CDOModelElementImpl] Setting client info: CDOFeature(ID=3D2, name=3D=
contents, type=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObjec=
t)) --> org.eclipse.emf.ecore.impl.EReferenceImpl@22ab57 (name: contents)=
(ordered: true, unique: true, lowerBound: 0, upperBound: -1) (changeable=
: true, volatile: false, transient: false, defaultValueLiteral: null, uns=
ettable: false, derived: false) (containment: true, resolveProxies: false=
)
main [CDOModelElementImpl] Setting client info: CDOFeature(ID=3D8, name=3D=
path, type=3DSTRING, referenceType=3Dnull) --> org.eclipse.emf.ecore.impl=
=2EEAttributeImpl@1eec35 (name: path) (ordered: true, unique: true, lower=
Bound: 0, upperBound: 1) (changeable: true, volatile: false, transient: f=
alse, defaultValueLiteral: null, unsettable: false, derived: false) (iD: =
false)
main [Lifecycle] Activating CDOSession[null/repo1]
main [Connector] Waiting for connection...
main [Lifecycle] Activating SignalProtocol[cdo]
main [Lifecycle] DUMP CDOClientProtocol@19
Protocol.channel =3D Channel[-32.768]
Protocol.infraStructure =3D CDOSession[null/repo1]
SignalProtocol.streamWrapper =3D null
SignalProtocol.signals =3D=20
SignalProtocol.nextCorrelationID =3D 1
main [Connector] Opening channel 0 with protocol cdo
main [ControlChannel] Registering channel 0 with protocol SignalProtocol[=
cdo]
main [BufferFactory] Created Buffer@20
main [BufferPool] Obtained Buffer@20
main [Channel] Handling buffer from client: Buffer@20 --> Channel[Control=
]
main [TCPSelector] Ordering client operation INTEREST WRITE java.nio.chan=
nels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocalhost/1=
27.0.0.1:2036] =3D true
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [Buffer] Writing 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f=20
TCPSelector [BufferPool] Retaining Buffer@20
TCPSelector [TCPSelector] Ordering client operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f=20
TCPSelector [Lifecycle] Activating SignalProtocol[cdo]
TCPSelector [Lifecycle] DUMP CDOServerProtocol@21
Protocol.channel =3D Channel[-32.768]
Protocol.infraStructure =3D org.eclipse.emf.cdo.internal.server.Containe=
rRepositoryProvider@238a47
SignalProtocol.streamWrapper =3D null
SignalProtocol.signals =3D=20
SignalProtocol.nextCorrelationID =3D 1
session =3D null
TCPSelector [Connector] Opening channel 0 with protocol cdo
TCPSelector [Lifecycle] Activating Channel[0]
TCPSelector [Lifecycle] Activating QueueWorkerWorkSerializer@22
TCPSelector [Lifecycle] DUMP QueueWorkerWorkSerializer@22
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@ae533a[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-4,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
TCPSelector [Lifecycle] DUMP Channel@23
channelID =3D 1
channelIndex =3D 0
connector =3D ServerTCPConnector[127.0.0.1:4.641]
receiveHandler =3D SignalProtocol[cdo]
receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e1e
receiveSerializer =3D QueueWorkerWorkSerializer@22
sendQueue =3D=20
TCPSelector [BufferFactory] Created Buffer@24
TCPSelector [BufferPool] Obtained Buffer@24
TCPSelector [Channel] Handling buffer from client: Buffer@24 --> Channel[=
Control]
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D true
TCPSelector [BufferPool] Retaining Buffer@20
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Buffer] Writing 4 bytes
03 00 00 01=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D false
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 4 bytes
03 00 00 01=20
TCPSelector [BufferPool] Retaining Buffer@20
main [Lifecycle] Activating Channel[0]
main [Lifecycle] Activating QueueWorkerWorkSerializer@25
main [Lifecycle] DUMP QueueWorkerWorkSerializer@25
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@401369[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-5,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
main [Lifecycle] DUMP Channel@26
channelID =3D 1
channelIndex =3D 0
connector =3D ClientTCPConnector[localhost:2.036]
receiveHandler =3D SignalProtocol[cdo]
receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e1e
receiveSerializer =3D QueueWorkerWorkSerializer@25
sendQueue =3D=20
main [RequestWithConfirmation] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D Requesting OpenSessionRequest
main [OpenSessionRequest] Writing repositoryName: repo1
main [BufferPool] Obtained Buffer@24
main [SignalProtocol] Put signal id 1
main [OpenSessionRequest] Writing disableLegacyObjects: false
main [Channel] Handling buffer from client: Buffer@24 --> Channel[0]
main [TCPSelector] Ordering client operation INTEREST WRITE java.nio.chan=
nels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocalhost/1=
27.0.0.1:2036] =3D true
main [RequestWithConfirmation] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D Confirming OpenSessionRequest
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [Buffer] Writing 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering client operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00=20
TCPSelector [Channel] Handling buffer from multiplexer: Buffer@20 --> Cha=
nnel[0]
Thread-4 [SignalProtocol] Received buffer for correlation 1
Thread-4 [SignalProtocol] Got signal id 1
Thread-6 [IndicationWithResponse] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D Indicating OpenSessionIndication
Thread-6 [OpenSessionIndication] Read repositoryName: repo1
Thread-6 [BufferPool] Retaining Buffer@20
Thread-6 [OpenSessionIndication] Read disableLegacyObjects: false
Thread-6 [IndicationWithResponse] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D Responding OpenSessionIndication
Thread-6 [SessionManager] Opening session 1
Thread-6 [Lifecycle] Activating Session[1, Channel[0]]
Thread-6 [Lifecycle] DUMP Session@27
sessionManager =3D SessionManager@4
protocol =3D SignalProtocol[cdo]
sessionID =3D 1
disableLegacyObjects =3D false
views =3D=20
knownTypes =3D=20
protocolListener =3D org.eclipse.emf.cdo.internal.server.Session$1@6e436=
5
Thread-6 [OpenSessionIndication] Writing sessionID: 1
Thread-6 [BufferPool] Obtained Buffer@24
Thread-6 [OpenSessionIndication] Writing repositoryUUID: 0fe540d7-7197-4a=
c8-89c2-6a5b7d654081
Thread-6 [Channel] Handling buffer from client: Buffer@24 --> Channel[0]
Thread-6 [TCPSelector] Ordering server operation INTEREST WRITE java.nio.=
channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.=
0.1:4641] =3D true
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Buffer] Writing 49 bytes (EOS)
00 00 00 00 00 00 00 01 01 00 24 30 66 65 35 34 30 64 37 2d 37 31 39 37 2=
d 34 61 63 38 2d 38 39 63 32 2d 36 61 35 62 37 64 36 35 34 30 38 31 00 00=
=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D false
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 49 bytes (EOS)
00 00 00 00 00 00 00 01 01 00 24 30 66 65 35 34 30 64 37 2d 37 31 39 37 2=
d 34 61 63 38 2d 38 39 63 32 2d 36 61 35 62 37 64 36 35 34 30 38 31 00 00=
=20
TCPSelector [Channel] Handling buffer from multiplexer: Buffer@20 --> Cha=
nnel[0]
Thread-5 [SignalProtocol] Received buffer for correlation -1
main [OpenSessionRequest] Read sessionID: 1
main [OpenSessionRequest] Read repositoryUUID: 0fe540d7-7197-4ac8-89c2-6a=
5b7d654081
main [BufferPool] Retaining Buffer@20
main [Lifecycle] Activating CDOSessionPackageManager@28
main [Lifecycle] DUMP CDOSessionPackageManager@28
CDOPackageManagerImpl.packages =3D=20
http://www.eclipse.org/emf/CDO/core/1.0.0=3DCDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull)
http://www.eclipse.org/emf/CDO/resource/1.0.0=3DCDOPackage(URI=3Dhttp=
://www.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3D=
false, metaIDRange=3Dnull)
CDOPackageManagerImpl.cdoCorePackage =3D CDOPackage(URI=3Dhttp://www.ecl=
ipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=
=3Dnull)
CDOPackageManagerImpl.cdoResourcePackage =3D CDOPackage(URI=3Dhttp://www=
=2Eeclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull)
session =3D CDOSession[ClientTCPConnector[localhost:2.036]/repo1]
main [Lifecycle] Activating CDORevisionManagerImpl@29
main [Lifecycle] DUMP CDORevisionManagerImpl@29
CDORevisionResolverImpl.revisions =3D=20
CDORevisionResolverImpl.currentLRUCapacity =3D 0
CDORevisionResolverImpl.revisedLRUCapacity =3D 0
CDORevisionResolverImpl.currentLRU =3D LRU[size=3D0, capacity=3D0]
CDORevisionResolverImpl.revisedLRU =3D LRU[size=3D0, capacity=3D0]
session =3D CDOSession[ClientTCPConnector[localhost:2.036]/repo1]
ruleManager =3D org.eclipse.emf.internal.cdo.analyzer.NOOPFetchRuleManag=
er@13e754f
main [Lifecycle] DUMP CDOSessionImpl@30
nextTemporaryID =3D -1
sessionID =3D 1
disableLegacyObjects =3D false
referenceChunkSize =3D -1
failOverStrategy =3D null
failOverStrategyListener =3D org.eclipse.emf.internal.cdo.CDOSessionImpl=
$1@15e234c
connector =3D ClientTCPConnector[localhost:2.036]
channel =3D Channel[0]
repositoryName =3D repo1
repositoryUUID =3D 0fe540d7-7197-4ac8-89c2-6a5b7d654081
packageRegistry =3D=20
packageManager =3D CDOSessionPackageManager@28
revisionManager =3D CDORevisionManagerImpl@29
idToMetaInstanceMap =3D=20
metaInstanceToIDMap =3D=20
types =3D=20
views =3D=20
lastViewID =3D 0
channelListener =3D org.eclipse.emf.internal.cdo.CDOSessionImpl$2@15f710=
7
BufferPoolMonitor [BufferPool] Collected buffer
BufferPoolMonitor [BufferPool] Collected buffer
main [CDOSessionImpl] Registering meta instance: -1 <-> org.eclipse.emf.c=
do.tests.model1.impl.Model1PackageImpl@84ce7a (name: model1) (nsURI: http=
://www.eclipse.org/emf/CDO/tests/model1/1.0.0, nsPrefix: model1)
main [CDOSessionImpl] Registering meta instance: -3 <-> org.eclipse.emf.e=
core.impl.EClassImpl@9505f (name: Address) (instanceClassName: null) (abs=
tract: false, interface: false)
main [CDOSessionImpl] Registering meta instance: -5 <-> org.eclipse.emf.e=
core.impl.EAttributeImpl@10fd7f6 (name: name) (ordered: true, unique: tru=
e, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tran=
sient: false, defaultValueLiteral: null, unsettable: false, derived: fals=
e) (iD: false)
main [CDOSessionImpl] Registering meta instance: -7 <-> org.eclipse.emf.e=
core.impl.EGenericTypeImpl@12b6c89 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -9 <-> org.eclipse.emf.e=
core.impl.EAttributeImpl@1e2befa (name: street) (ordered: true, unique: t=
rue, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tr=
ansient: false, defaultValueLiteral: null, unsettable: false, derived: fa=
lse) (iD: false)
main [CDOSessionImpl] Registering meta instance: -11 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@1682598 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -13 <-> org.eclipse.emf.=
ecore.impl.EAttributeImpl@7c3885 (name: city) (ordered: true, unique: tru=
e, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tran=
sient: false, defaultValueLiteral: null, unsettable: false, derived: fals=
e) (iD: false)
main [CDOSessionImpl] Registering meta instance: -15 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@162e295 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -17 <-> org.eclipse.emf.=
ecore.impl.EClassImpl@17ba38f (name: Company) (instanceClassName: null) (=
abstract: false, interface: false)
main [CDOSessionImpl] Registering meta instance: -19 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@109de5b (name: categories) (ordered: true, uniq=
ue: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fal=
se, transient: false, defaultValueLiteral: null, unsettable: false, deriv=
ed: false) (containment: true, resolveProxies: false)
main [CDOSessionImpl] Registering meta instance: -21 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@e53220 (expression: Category)
main [CDOSessionImpl] Registering meta instance: -23 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@13e0aba (name: suppliers) (ordered: true, uniqu=
e: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fals=
e, transient: false, defaultValueLiteral: null, unsettable: false, derive=
d: false) (containment: true, resolveProxies: false)
main [CDOSessionImpl] Registering meta instance: -25 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@3257b8 (expression: Supplier)
main [CDOSessionImpl] Registering meta instance: -27 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@11d2572 (name: customers) (ordered: true, uniqu=
e: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fals=
e, transient: false, defaultValueLiteral: null, unsettable: false,
|
|
| | |
| Re: [CDO] how to handle object update conflicts [message #102044 is a reply to message #101971] |
Thu, 08 November 2007 14:33 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark Geib schrieb:
> Eike,
>
> I am not at work for about an hour or so to try your test.
>
> However, maybe I was not clear in the desciption of my problem. After
> I do the rollback I can go ahead and modify the object and a commit
> succeeds. The problem is that the changes are not save in the
> database. That is, if I exit both clients and then restart only the
> first saved changes to the object are present. The changes made after
> the rollback and re-commit are lost.
Ok, I really misinterpreted it first.
But I double checked your "new" scenario and it works perfectly for me.
Have you also tried to verify it with purely CDO provided means? That is
tests.model1 + CDO UI
Another thought: What you describe here could (but doesn't need to)
indicate a problem in the client, although I can't reproduce it here. A
bug in the server would be more likely if the problem occurs after you
restarted the server, but you mention to only restart the clients. I
mean, even if the server would forget to save changes to the database,
it would have the most recent ones in its cache.
> Am I correct in assuming that your test runs in a single process.?
> That seems to be a different environment that I am running, with two
> instances on two different machines. Could that effect the results.?
In general I can't exclude such effect for 100% but I think it's rather
unlikely.
The JUnit tests run in a single process and even without real database
(I use the NOOPStore).
But I've worked many times through all your instructions with a proper 4
process setup: Separate db (Derby+HSQLDB), separate CDO Server + 2
separate UI clients.
Not a single sign that something is wrong.
I fear we have only few options:
1) You get it by looking at your logs (maybe add some traces here and there)
2) You get it with the debugger (which is your friend, i know ;-) )
3) You send me your application via email and I debug it for you
4) You have an idea that I didn't have
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102088 is a reply to message #102044] |
Thu, 08 November 2007 17:31 |
| Eclipse User |
|
|
|
Eike,
I have looking at the logs carefully. After I do the rollback, then
modify the same object that was conflicted, then do a commit I do not
see any traffice for the save/commit. I do not get the event for the
start of the commit or end of the commit.
Do I need to create a new transaction after the rollback, or do
something to prepare the old transaction for use again after the rollback.??
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I am not at work for about an hour or so to try your test.
>>
>> However, maybe I was not clear in the desciption of my problem. After
>> I do the rollback I can go ahead and modify the object and a commit
>> succeeds. The problem is that the changes are not save in the
>> database. That is, if I exit both clients and then restart only the
>> first saved changes to the object are present. The changes made after
>> the rollback and re-commit are lost.
> Ok, I really misinterpreted it first.
> But I double checked your "new" scenario and it works perfectly for me.
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
>
> Another thought: What you describe here could (but doesn't need to)
> indicate a problem in the client, although I can't reproduce it here. A
> bug in the server would be more likely if the problem occurs after you
> restarted the server, but you mention to only restart the clients. I
> mean, even if the server would forget to save changes to the database,
> it would have the most recent ones in its cache.
>
>> Am I correct in assuming that your test runs in a single process.?
>> That seems to be a different environment that I am running, with two
>> instances on two different machines. Could that effect the results.?
> In general I can't exclude such effect for 100% but I think it's rather
> unlikely.
> The JUnit tests run in a single process and even without real database
> (I use the NOOPStore).
> But I've worked many times through all your instructions with a proper 4
> process setup: Separate db (Derby+HSQLDB), separate CDO Server + 2
> separate UI clients.
> Not a single sign that something is wrong.
>
> I fear we have only few options:
> 1) You get it by looking at your logs (maybe add some traces here and
> there)
> 2) You get it with the debugger (which is your friend, i know ;-) )
> 3) You send me your application via email and I debug it for you
> 4) You have an idea that I didn't have
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102115 is a reply to message #102088] |
Thu, 08 November 2007 17:58 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark Geib schrieb:
> Eike,
>
> I have looking at the logs carefully. After I do the rollback, then
> modify the same object that was conflicted, then do a commit I do not
> see any traffice for the save/commit. I do not get the event for the
> start of the commit or end of the commit.
There should be traffic if the transaction is really dirty. If not, it's
a sign that the problem is in the client. There you can use the Net4j
Container view and the Net4j Introspector view to click at runtime
through the user interface elements down to the core elements and browse
their fields. May be this helps you track it down further.
From the log you should be able to locate an appropriate line for a
breakpoint to start debugging at. A high entry could be in the
CommitTransactionAction (if you use that to commit). A low entry could
be CDOTransactionImpl.commit() which is still before the statemachine
for particular objects is triggered.
> Do I need to create a new transaction after the rollback, or do
> something to prepare the old transaction for use again after the
> rollback.??
No, rollback() is sufficient. After that call the transaction should be
non-dirty and all objects with newer remote version should be proxies,
all other objects should be clean.
Have you also tried to verify it with purely CDO provided means? That is
tests.model1 + CDO UI
Just that we have an indication whether the issue occurs there, too.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
..
>
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I am not at work for about an hour or so to try your test.
>>>
>>> However, maybe I was not clear in the desciption of my problem.
>>> After I do the rollback I can go ahead and modify the object and a
>>> commit succeeds. The problem is that the changes are not save in the
>>> database. That is, if I exit both clients and then restart only the
>>> first saved changes to the object are present. The changes made
>>> after the rollback and re-commit are lost.
>> Ok, I really misinterpreted it first.
>> But I double checked your "new" scenario and it works perfectly for me.
>> Have you also tried to verify it with purely CDO provided means? That
>> is tests.model1 + CDO UI
>>
>> Another thought: What you describe here could (but doesn't need to)
>> indicate a problem in the client, although I can't reproduce it here.
>> A bug in the server would be more likely if the problem occurs after
>> you restarted the server, but you mention to only restart the
>> clients. I mean, even if the server would forget to save changes to
>> the database, it would have the most recent ones in its cache.
>>
>>> Am I correct in assuming that your test runs in a single process.?
>>> That seems to be a different environment that I am running, with two
>>> instances on two different machines. Could that effect the results.?
>> In general I can't exclude such effect for 100% but I think it's
>> rather unlikely.
>> The JUnit tests run in a single process and even without real
>> database (I use the NOOPStore).
>> But I've worked many times through all your instructions with a
>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>> Server + 2 separate UI clients.
>> Not a single sign that something is wrong.
>>
>> I fear we have only few options:
>> 1) You get it by looking at your logs (maybe add some traces here and
>> there)
>> 2) You get it with the debugger (which is your friend, i know ;-) )
>> 3) You send me your application via email and I debug it for you
>> 4) You have an idea that I didn't have
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102130 is a reply to message #102115] |
Thu, 08 November 2007 18:49 |
| Eclipse User |
|
|
|
Eike,
I quickly debugged my save method and inspected the transaction. It is
not dirty, that must be the issue.
Why is not dirty, I have changed an attribute.
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I have looking at the logs carefully. After I do the rollback, then
>> modify the same object that was conflicted, then do a commit I do not
>> see any traffice for the save/commit. I do not get the event for the
>> start of the commit or end of the commit.
> There should be traffic if the transaction is really dirty. If not, it's
> a sign that the problem is in the client. There you can use the Net4j
> Container view and the Net4j Introspector view to click at runtime
> through the user interface elements down to the core elements and browse
> their fields. May be this helps you track it down further.
>
> From the log you should be able to locate an appropriate line for a
> breakpoint to start debugging at. A high entry could be in the
> CommitTransactionAction (if you use that to commit). A low entry could
> be CDOTransactionImpl.commit() which is still before the statemachine
> for particular objects is triggered.
>
>> Do I need to create a new transaction after the rollback, or do
>> something to prepare the old transaction for use again after the
>> rollback.??
> No, rollback() is sufficient. After that call the transaction should be
> non-dirty and all objects with newer remote version should be proxies,
> all other objects should be clean.
>
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
> Just that we have an indication whether the issue occurs there, too.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> .
>
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I am not at work for about an hour or so to try your test.
>>>>
>>>> However, maybe I was not clear in the desciption of my problem.
>>>> After I do the rollback I can go ahead and modify the object and a
>>>> commit succeeds. The problem is that the changes are not save in the
>>>> database. That is, if I exit both clients and then restart only the
>>>> first saved changes to the object are present. The changes made
>>>> after the rollback and re-commit are lost.
>>> Ok, I really misinterpreted it first.
>>> But I double checked your "new" scenario and it works perfectly for me.
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>>
>>> Another thought: What you describe here could (but doesn't need to)
>>> indicate a problem in the client, although I can't reproduce it here.
>>> A bug in the server would be more likely if the problem occurs after
>>> you restarted the server, but you mention to only restart the
>>> clients. I mean, even if the server would forget to save changes to
>>> the database, it would have the most recent ones in its cache.
>>>
>>>> Am I correct in assuming that your test runs in a single process.?
>>>> That seems to be a different environment that I am running, with two
>>>> instances on two different machines. Could that effect the results.?
>>> In general I can't exclude such effect for 100% but I think it's
>>> rather unlikely.
>>> The JUnit tests run in a single process and even without real
>>> database (I use the NOOPStore).
>>> But I've worked many times through all your instructions with a
>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>> Server + 2 separate UI clients.
>>> Not a single sign that something is wrong.
>>>
>>> I fear we have only few options:
>>> 1) You get it by looking at your logs (maybe add some traces here and
>>> there)
>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>> 3) You send me your application via email and I debug it for you
>>> 4) You have an idea that I didn't have
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102143 is a reply to message #102115] |
Thu, 08 November 2007 19:02 |
| Eclipse User |
|
|
|
Eike,
I also see in the logs that the state of the object is CONFLICT rather
than DIRTY prior to the commit which does nothing.
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I have looking at the logs carefully. After I do the rollback, then
>> modify the same object that was conflicted, then do a commit I do not
>> see any traffice for the save/commit. I do not get the event for the
>> start of the commit or end of the commit.
> There should be traffic if the transaction is really dirty. If not, it's
> a sign that the problem is in the client. There you can use the Net4j
> Container view and the Net4j Introspector view to click at runtime
> through the user interface elements down to the core elements and browse
> their fields. May be this helps you track it down further.
>
> From the log you should be able to locate an appropriate line for a
> breakpoint to start debugging at. A high entry could be in the
> CommitTransactionAction (if you use that to commit). A low entry could
> be CDOTransactionImpl.commit() which is still before the statemachine
> for particular objects is triggered.
>
>> Do I need to create a new transaction after the rollback, or do
>> something to prepare the old transaction for use again after the
>> rollback.??
> No, rollback() is sufficient. After that call the transaction should be
> non-dirty and all objects with newer remote version should be proxies,
> all other objects should be clean.
>
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
> Just that we have an indication whether the issue occurs there, too.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> .
>
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I am not at work for about an hour or so to try your test.
>>>>
>>>> However, maybe I was not clear in the desciption of my problem.
>>>> After I do the rollback I can go ahead and modify the object and a
>>>> commit succeeds. The problem is that the changes are not save in the
>>>> database. That is, if I exit both clients and then restart only the
>>>> first saved changes to the object are present. The changes made
>>>> after the rollback and re-commit are lost.
>>> Ok, I really misinterpreted it first.
>>> But I double checked your "new" scenario and it works perfectly for me.
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>>
>>> Another thought: What you describe here could (but doesn't need to)
>>> indicate a problem in the client, although I can't reproduce it here.
>>> A bug in the server would be more likely if the problem occurs after
>>> you restarted the server, but you mention to only restart the
>>> clients. I mean, even if the server would forget to save changes to
>>> the database, it would have the most recent ones in its cache.
>>>
>>>> Am I correct in assuming that your test runs in a single process.?
>>>> That seems to be a different environment that I am running, with two
>>>> instances on two different machines. Could that effect the results.?
>>> In general I can't exclude such effect for 100% but I think it's
>>> rather unlikely.
>>> The JUnit tests run in a single process and even without real
>>> database (I use the NOOPStore).
>>> But I've worked many times through all your instructions with a
>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>> Server + 2 separate UI clients.
>>> Not a single sign that something is wrong.
>>>
>>> I fear we have only few options:
>>> 1) You get it by looking at your logs (maybe add some traces here and
>>> there)
>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>> 3) You send me your application via email and I debug it for you
>>> 4) You have an idea that I didn't have
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102157 is a reply to message #102143] |
Fri, 09 November 2007 01:44 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark,
I think this is the root cause. The transaction not being dirty is most
probably a followup problem because object state CONFLICT can't be left
via event WRITE, see CDOStateMachine:
init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
Please use the Introspector view to verify the state of the conflicting
objects and the transaction itself before and after the rollback(). The
CDOTransactionImpl.cleanUp() method should bring the transaction in a
proper state after commit() and rollback():
public void rollback(boolean remote)
{
try
{
if (!newResources.isEmpty())
{
for (CDOObject newResource : newResources.values())
{
removeObject(newResource.cdoID());
getResourceSet().getResources().remove(newResource);
}
}
if (!newObjects.isEmpty())
{
for (CDOObject newObject : newObjects.values())
{
removeObject(newObject.cdoID());
}
}
if (!dirtyObjects.isEmpty())
{
for (CDOObject dirtyObject : dirtyObjects.values())
{
CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
}
}
cleanUp();
Map<CDOID, CDOID> idMappings = Collections.emptyMap();
fireEvent(new
FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
}
catch (RuntimeException ex)
{
throw ex;
}
catch (Exception ex)
{
throw new TransactionException(ex);
}
}
private void cleanUp()
{
newPackages = null;
newResources.clear();
newObjects.clear();
dirtyObjects.clear();
dirty = false;
conflict = false;
nextTemporaryID = INITIAL_TEMPORARY_ID;
}
BTW. I checked again that all the states have proper values all over the
process here.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> I also see in the logs that the state of the object is CONFLICT rather
> than DIRTY prior to the commit which does nothing.
>
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I have looking at the logs carefully. After I do the rollback, then
>>> modify the same object that was conflicted, then do a commit I do
>>> not see any traffice for the save/commit. I do not get the event for
>>> the start of the commit or end of the commit.
>> There should be traffic if the transaction is really dirty. If not,
>> it's a sign that the problem is in the client. There you can use the
>> Net4j Container view and the Net4j Introspector view to click at
>> runtime through the user interface elements down to the core elements
>> and browse their fields. May be this helps you track it down further.
>>
>> From the log you should be able to locate an appropriate line for a
>> breakpoint to start debugging at. A high entry could be in the
>> CommitTransactionAction (if you use that to commit). A low entry
>> could be CDOTransactionImpl.commit() which is still before the
>> statemachine for particular objects is triggered.
>>
>>> Do I need to create a new transaction after the rollback, or do
>>> something to prepare the old transaction for use again after the
>>> rollback.??
>> No, rollback() is sufficient. After that call the transaction should
>> be non-dirty and all objects with newer remote version should be
>> proxies, all other objects should be clean.
>>
>> Have you also tried to verify it with purely CDO provided means? That
>> is tests.model1 + CDO UI
>> Just that we have an indication whether the issue occurs there, too.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>> .
>>
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I am not at work for about an hour or so to try your test.
>>>>>
>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>> commit succeeds. The problem is that the changes are not save in
>>>>> the database. That is, if I exit both clients and then restart
>>>>> only the first saved changes to the object are present. The
>>>>> changes made after the rollback and re-commit are lost.
>>>> Ok, I really misinterpreted it first.
>>>> But I double checked your "new" scenario and it works perfectly for
>>>> me.
>>>> Have you also tried to verify it with purely CDO provided means?
>>>> That is tests.model1 + CDO UI
>>>>
>>>> Another thought: What you describe here could (but doesn't need
>>>> to) indicate a problem in the client, although I can't reproduce
>>>> it here. A bug in the server would be more likely if the problem
>>>> occurs after you restarted the server, but you mention to only
>>>> restart the clients. I mean, even if the server would forget to
>>>> save changes to the database, it would have the most recent ones in
>>>> its cache.
>>>>
>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>> That seems to be a different environment that I am running, with
>>>>> two instances on two different machines. Could that effect the
>>>>> results.?
>>>> In general I can't exclude such effect for 100% but I think it's
>>>> rather unlikely.
>>>> The JUnit tests run in a single process and even without real
>>>> database (I use the NOOPStore).
>>>> But I've worked many times through all your instructions with a
>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>> Server + 2 separate UI clients.
>>>> Not a single sign that something is wrong.
>>>>
>>>> I fear we have only few options:
>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>> and there)
>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>> 3) You send me your application via email and I debug it for you
>>>> 4) You have an idea that I didn't have
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102259 is a reply to message #102157] |
Fri, 09 November 2007 11:26 |
| Eclipse User |
|
|
|
Eike,
I stepped through my event handler and watched the log. During the time
my code is handling the conflict I see everything look normal. When the
listener exits the state is CLEAN, then I continue stepping and the
method ConflictTransition.execute() then sets the state to CONFLICT.
It looks like what ever I do to effect the state of the object is
overwritten by this code setting state back to CONFLICT.
Mark.
Eike Stepper wrote:
> Mark,
>
> I think this is the root cause. The transaction not being dirty is most
> probably a followup problem because object state CONFLICT can't be left
> via event WRITE, see CDOStateMachine:
>
> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>
> Please use the Introspector view to verify the state of the conflicting
> objects and the transaction itself before and after the rollback(). The
> CDOTransactionImpl.cleanUp() method should bring the transaction in a
> proper state after commit() and rollback():
>
> public void rollback(boolean remote)
> {
> try
> {
> if (!newResources.isEmpty())
> {
> for (CDOObject newResource : newResources.values())
> {
> removeObject(newResource.cdoID());
> getResourceSet().getResources().remove(newResource);
> }
> }
>
> if (!newObjects.isEmpty())
> {
> for (CDOObject newObject : newObjects.values())
> {
> removeObject(newObject.cdoID());
> }
> }
>
> if (!dirtyObjects.isEmpty())
> {
> for (CDOObject dirtyObject : dirtyObjects.values())
> {
>
> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
> }
> }
>
> cleanUp();
> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
> fireEvent(new
> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
> }
> catch (RuntimeException ex)
> {
> throw ex;
> }
> catch (Exception ex)
> {
> throw new TransactionException(ex);
> }
> }
>
> private void cleanUp()
> {
> newPackages = null;
> newResources.clear();
> newObjects.clear();
> dirtyObjects.clear();
> dirty = false;
> conflict = false;
> nextTemporaryID = INITIAL_TEMPORARY_ID;
> }
>
> BTW. I checked again that all the states have proper values all over the
> process here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I also see in the logs that the state of the object is CONFLICT rather
>> than DIRTY prior to the commit which does nothing.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I have looking at the logs carefully. After I do the rollback, then
>>>> modify the same object that was conflicted, then do a commit I do
>>>> not see any traffice for the save/commit. I do not get the event for
>>>> the start of the commit or end of the commit.
>>> There should be traffic if the transaction is really dirty. If not,
>>> it's a sign that the problem is in the client. There you can use the
>>> Net4j Container view and the Net4j Introspector view to click at
>>> runtime through the user interface elements down to the core elements
>>> and browse their fields. May be this helps you track it down further.
>>>
>>> From the log you should be able to locate an appropriate line for a
>>> breakpoint to start debugging at. A high entry could be in the
>>> CommitTransactionAction (if you use that to commit). A low entry
>>> could be CDOTransactionImpl.commit() which is still before the
>>> statemachine for particular objects is triggered.
>>>
>>>> Do I need to create a new transaction after the rollback, or do
>>>> something to prepare the old transaction for use again after the
>>>> rollback.??
>>> No, rollback() is sufficient. After that call the transaction should
>>> be non-dirty and all objects with newer remote version should be
>>> proxies, all other objects should be clean.
>>>
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>> Just that we have an indication whether the issue occurs there, too.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>> .
>>>
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>
>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>>> commit succeeds. The problem is that the changes are not save in
>>>>>> the database. That is, if I exit both clients and then restart
>>>>>> only the first saved changes to the object are present. The
>>>>>> changes made after the rollback and re-commit are lost.
>>>>> Ok, I really misinterpreted it first.
>>>>> But I double checked your "new" scenario and it works perfectly for
>>>>> me.
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>>
>>>>> Another thought: What you describe here could (but doesn't need
>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>> it here. A bug in the server would be more likely if the problem
>>>>> occurs after you restarted the server, but you mention to only
>>>>> restart the clients. I mean, even if the server would forget to
>>>>> save changes to the database, it would have the most recent ones in
>>>>> its cache.
>>>>>
>>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>>> That seems to be a different environment that I am running, with
>>>>>> two instances on two different machines. Could that effect the
>>>>>> results.?
>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>> rather unlikely.
>>>>> The JUnit tests run in a single process and even without real
>>>>> database (I use the NOOPStore).
>>>>> But I've worked many times through all your instructions with a
>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>> Server + 2 separate UI clients.
>>>>> Not a single sign that something is wrong.
>>>>>
>>>>> I fear we have only few options:
>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>> and there)
>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>> 3) You send me your application via email and I debug it for you
>>>>> 4) You have an idea that I didn't have
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102270 is a reply to message #102157] |
Fri, 09 November 2007 12:00 |
| Eclipse User |
|
|
|
Eike,
OK, I changed my approach with some success.
Instead of adding the listener and handling the conflict when the second
client saves I now check the transaction in my save method. If the
transaction is dirty and conflicted then I just rollback and commit. Now
everything is useable, that is, I can then re-modify the objects and do
a successful commit from client 1.
Mark.
Eike Stepper wrote:
> Mark,
>
> I think this is the root cause. The transaction not being dirty is most
> probably a followup problem because object state CONFLICT can't be left
> via event WRITE, see CDOStateMachine:
>
> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>
> Please use the Introspector view to verify the state of the conflicting
> objects and the transaction itself before and after the rollback(). The
> CDOTransactionImpl.cleanUp() method should bring the transaction in a
> proper state after commit() and rollback():
>
> public void rollback(boolean remote)
> {
> try
> {
> if (!newResources.isEmpty())
> {
> for (CDOObject newResource : newResources.values())
> {
> removeObject(newResource.cdoID());
> getResourceSet().getResources().remove(newResource);
> }
> }
>
> if (!newObjects.isEmpty())
> {
> for (CDOObject newObject : newObjects.values())
> {
> removeObject(newObject.cdoID());
> }
> }
>
> if (!dirtyObjects.isEmpty())
> {
> for (CDOObject dirtyObject : dirtyObjects.values())
> {
>
> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
> }
> }
>
> cleanUp();
> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
> fireEvent(new
> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
> }
> catch (RuntimeException ex)
> {
> throw ex;
> }
> catch (Exception ex)
> {
> throw new TransactionException(ex);
> }
> }
>
> private void cleanUp()
> {
> newPackages = null;
> newResources.clear();
> newObjects.clear();
> dirtyObjects.clear();
> dirty = false;
> conflict = false;
> nextTemporaryID = INITIAL_TEMPORARY_ID;
> }
>
> BTW. I checked again that all the states have proper values all over the
> process here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I also see in the logs that the state of the object is CONFLICT rather
>> than DIRTY prior to the commit which does nothing.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I have looking at the logs carefully. After I do the rollback, then
>>>> modify the same object that was conflicted, then do a commit I do
>>>> not see any traffice for the save/commit. I do not get the event for
>>>> the start of the commit or end of the commit.
>>> There should be traffic if the transaction is really dirty. If not,
>>> it's a sign that the problem is in the client. There you can use the
>>> Net4j Container view and the Net4j Introspector view to click at
>>> runtime through the user interface elements down to the core elements
>>> and browse their fields. May be this helps you track it down further.
>>>
>>> From the log you should be able to locate an appropriate line for a
>>> breakpoint to start debugging at. A high entry could be in the
>>> CommitTransactionAction (if you use that to commit). A low entry
>>> could be CDOTransactionImpl.commit() which is still before the
>>> statemachine for particular objects is triggered.
>>>
>>>> Do I need to create a new transaction after the rollback, or do
>>>> something to prepare the old transaction for use again after the
>>>> rollback.??
>>> No, rollback() is sufficient. After that call the transaction should
>>> be non-dirty and all objects with newer remote version should be
>>> proxies, all other objects should be clean.
>>>
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>> Just that we have an indication whether the issue occurs there, too.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>> .
>>>
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>
>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>>> commit succeeds. The problem is that the changes are not save in
>>>>>> the database. That is, if I exit both clients and then restart
>>>>>> only the first saved changes to the object are present. The
>>>>>> changes made after the rollback and re-commit are lost.
>>>>> Ok, I really misinterpreted it first.
>>>>> But I double checked your "new" scenario and it works perfectly for
>>>>> me.
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>>
>>>>> Another thought: What you describe here could (but doesn't need
>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>> it here. A bug in the server would be more likely if the problem
>>>>> occurs after you restarted the server, but you mention to only
>>>>> restart the clients. I mean, even if the server would forget to
>>>>> save changes to the database, it would have the most recent ones in
>>>>> its cache.
>>>>>
>>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>>> That seems to be a different environment that I am running, with
>>>>>> two instances on two different machines. Could that effect the
>>>>>> results.?
>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>> rather unlikely.
>>>>> The JUnit tests run in a single process and even without real
>>>>> database (I use the NOOPStore).
>>>>> But I've worked many times through all your instructions with a
>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>> Server + 2 separate UI clients.
>>>>> Not a single sign that something is wrong.
>>>>>
>>>>> I fear we have only few options:
>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>> and there)
>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>> 3) You send me your application via email and I debug it for you
>>>>> 4) You have an idea that I didn't have
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102288 is a reply to message #102270] |
Fri, 09 November 2007 13:13 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark,
From your writing I get the impression that the cause was in your
client code.
I must admit that I don't have a clear picture of what was wrong and to
what you changed it.
If you say it was a silly fault, it's ok for me ;-)
If you feel that the CDO API is not clear enough or the wiki could have
a FAQ entry to prevent others from running into an open trap, then I'd
appreciate if you make it clear with code examples, so that I can
publish it.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> OK, I changed my approach with some success.
>
> Instead of adding the listener and handling the conflict when the
> second client saves I now check the transaction in my save method. If
> the transaction is dirty and conflicted then I just rollback and
> commit. Now everything is useable, that is, I can then re-modify the
> objects and do a successful commit from client 1.
>
> Mark.
>
> Eike Stepper wrote:
>> Mark,
>>
>> I think this is the root cause. The transaction not being dirty is
>> most probably a followup problem because object state CONFLICT can't
>> be left via event WRITE, see CDOStateMachine:
>>
>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>
>> Please use the Introspector view to verify the state of the
>> conflicting objects and the transaction itself before and after the
>> rollback(). The CDOTransactionImpl.cleanUp() method should bring the
>> transaction in a proper state after commit() and rollback():
>>
>> public void rollback(boolean remote)
>> {
>> try
>> {
>> if (!newResources.isEmpty())
>> {
>> for (CDOObject newResource : newResources.values())
>> {
>> removeObject(newResource.cdoID());
>> getResourceSet().getResources().remove(newResource);
>> }
>> }
>>
>> if (!newObjects.isEmpty())
>> {
>> for (CDOObject newObject : newObjects.values())
>> {
>> removeObject(newObject.cdoID());
>> }
>> }
>>
>> if (!dirtyObjects.isEmpty())
>> {
>> for (CDOObject dirtyObject : dirtyObjects.values())
>> {
>>
>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>> remote);
>> }
>> }
>>
>> cleanUp();
>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>> fireEvent(new
>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>> idMappings));
>> }
>> catch (RuntimeException ex)
>> {
>> throw ex;
>> }
>> catch (Exception ex)
>> {
>> throw new TransactionException(ex);
>> }
>> }
>>
>> private void cleanUp()
>> {
>> newPackages = null;
>> newResources.clear();
>> newObjects.clear();
>> dirtyObjects.clear();
>> dirty = false;
>> conflict = false;
>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>> }
>>
>> BTW. I checked again that all the states have proper values all over
>> the process here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>
>>
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I also see in the logs that the state of the object is CONFLICT
>>> rather than DIRTY prior to the commit which does nothing.
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>> then modify the same object that was conflicted, then do a commit
>>>>> I do not see any traffice for the save/commit. I do not get the
>>>>> event for the start of the commit or end of the commit.
>>>> There should be traffic if the transaction is really dirty. If not,
>>>> it's a sign that the problem is in the client. There you can use
>>>> the Net4j Container view and the Net4j Introspector view to click
>>>> at runtime through the user interface elements down to the core
>>>> elements and browse their fields. May be this helps you track it
>>>> down further.
>>>>
>>>> From the log you should be able to locate an appropriate line for
>>>> a breakpoint to start debugging at. A high entry could be in the
>>>> CommitTransactionAction (if you use that to commit). A low entry
>>>> could be CDOTransactionImpl.commit() which is still before the
>>>> statemachine for particular objects is triggered.
>>>>
>>>>> Do I need to create a new transaction after the rollback, or do
>>>>> something to prepare the old transaction for use again after the
>>>>> rollback.??
>>>> No, rollback() is sufficient. After that call the transaction
>>>> should be non-dirty and all objects with newer remote version
>>>> should be proxies, all other objects should be clean.
>>>>
>>>> Have you also tried to verify it with purely CDO provided means?
>>>> That is tests.model1 + CDO UI
>>>> Just that we have an indication whether the issue occurs there, too.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>> .
>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>
>>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>>> After I do the rollback I can go ahead and modify the object and
>>>>>>> a commit succeeds. The problem is that the changes are not save
>>>>>>> in the database. That is, if I exit both clients and then
>>>>>>> restart only the first saved changes to the object are present.
>>>>>>> The changes made after the rollback and re-commit are lost.
>>>>>> Ok, I really misinterpreted it first.
>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>> for me.
>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>> That is tests.model1 + CDO UI
>>>>>>
>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>>> it here. A bug in the server would be more likely if the problem
>>>>>> occurs after you restarted the server, but you mention to only
>>>>>> restart the clients. I mean, even if the server would forget to
>>>>>> save changes to the database, it would have the most recent ones
>>>>>> in its cache.
>>>>>>
>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>> process.? That seems to be a different environment that I am
>>>>>>> running, with two instances on two different machines. Could
>>>>>>> that effect the results.?
>>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>>> rather unlikely.
>>>>>> The JUnit tests run in a single process and even without real
>>>>>> database (I use the NOOPStore).
>>>>>> But I've worked many times through all your instructions with a
>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>>> Server + 2 separate UI clients.
>>>>>> Not a single sign that something is wrong.
>>>>>>
>>>>>> I fear we have only few options:
>>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>>> and there)
>>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>>> 3) You send me your application via email and I debug it for you
>>>>>> 4) You have an idea that I didn't have
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102295 is a reply to message #102288] |
Fri, 09 November 2007 13:16 |
| Eclipse User |
|
|
|
Eike,
I guess I was a bit confused that I could not do anything in the event
handler that effected the object state. It would seem that I should be
able to take some action there to handle the event, like doing a
rollback, etc. I understand that the state machine must control the state.
I do have a couple questions.
o Can I tell what objects are deleted in the transaction.?? I can get
the dirty and new, be not the deleted.
o Does it make sense to undo my command stack when ever I call rollback
on a transaction, to keep my GUI consistent with my model objects.?? I
am still working on this...
o Do you any kind of roadmap for CDO. I am planning to release my system
using CDO very soon and need some help on when to freeze the CDO/Net4J
versions. I had planned to use a real release of CDO when I do my
release so that I do not build and release something slightly different
than that provided on the eclipse site for CDO.
Mark.
Eike Stepper wrote:
> Mark,
>
> From your writing I get the impression that the cause was in your
> client code.
> I must admit that I don't have a clear picture of what was wrong and to
> what you changed it.
> If you say it was a silly fault, it's ok for me ;-)
> If you feel that the CDO API is not clear enough or the wiki could have
> a FAQ entry to prevent others from running into an open trap, then I'd
> appreciate if you make it clear with code examples, so that I can
> publish it.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> OK, I changed my approach with some success.
>>
>> Instead of adding the listener and handling the conflict when the
>> second client saves I now check the transaction in my save method. If
>> the transaction is dirty and conflicted then I just rollback and
>> commit. Now everything is useable, that is, I can then re-modify the
>> objects and do a successful commit from client 1.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark,
>>>
>>> I think this is the root cause. The transaction not being dirty is
>>> most probably a followup problem because object state CONFLICT can't
>>> be left via event WRITE, see CDOStateMachine:
>>>
>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>
>>> Please use the Introspector view to verify the state of the
>>> conflicting objects and the transaction itself before and after the
>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring the
>>> transaction in a proper state after commit() and rollback():
>>>
>>> public void rollback(boolean remote)
>>> {
>>> try
>>> {
>>> if (!newResources.isEmpty())
>>> {
>>> for (CDOObject newResource : newResources.values())
>>> {
>>> removeObject(newResource.cdoID());
>>> getResourceSet().getResources().remove(newResource);
>>> }
>>> }
>>>
>>> if (!newObjects.isEmpty())
>>> {
>>> for (CDOObject newObject : newObjects.values())
>>> {
>>> removeObject(newObject.cdoID());
>>> }
>>> }
>>>
>>> if (!dirtyObjects.isEmpty())
>>> {
>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>> {
>>>
>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>> remote);
>>> }
>>> }
>>>
>>> cleanUp();
>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>> fireEvent(new
>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>> idMappings));
>>> }
>>> catch (RuntimeException ex)
>>> {
>>> throw ex;
>>> }
>>> catch (Exception ex)
>>> {
>>> throw new TransactionException(ex);
>>> }
>>> }
>>>
>>> private void cleanUp()
>>> {
>>> newPackages = null;
>>> newResources.clear();
>>> newObjects.clear();
>>> dirtyObjects.clear();
>>> dirty = false;
>>> conflict = false;
>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>> }
>>>
>>> BTW. I checked again that all the states have proper values all over
>>> the process here.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>>
>>>
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I also see in the logs that the state of the object is CONFLICT
>>>> rather than DIRTY prior to the commit which does nothing.
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>> then modify the same object that was conflicted, then do a commit
>>>>>> I do not see any traffice for the save/commit. I do not get the
>>>>>> event for the start of the commit or end of the commit.
>>>>> There should be traffic if the transaction is really dirty. If not,
>>>>> it's a sign that the problem is in the client. There you can use
>>>>> the Net4j Container view and the Net4j Introspector view to click
>>>>> at runtime through the user interface elements down to the core
>>>>> elements and browse their fields. May be this helps you track it
>>>>> down further.
>>>>>
>>>>> From the log you should be able to locate an appropriate line for
>>>>> a breakpoint to start debugging at. A high entry could be in the
>>>>> CommitTransactionAction (if you use that to commit). A low entry
>>>>> could be CDOTransactionImpl.commit() which is still before the
>>>>> statemachine for particular objects is triggered.
>>>>>
>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>> something to prepare the old transaction for use again after the
>>>>>> rollback.??
>>>>> No, rollback() is sufficient. After that call the transaction
>>>>> should be non-dirty and all objects with newer remote version
>>>>> should be proxies, all other objects should be clean.
>>>>>
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>
>>>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>>>> After I do the rollback I can go ahead and modify the object and
>>>>>>>> a commit succeeds. The problem is that the changes are not save
>>>>>>>> in the database. That is, if I exit both clients and then
>>>>>>>> restart only the first saved changes to the object are present.
>>>>>>>> The changes made after the rollback and re-commit are lost.
>>>>>>> Ok, I really misinterpreted it first.
>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>> for me.
>>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>>> That is tests.model1 + CDO UI
>>>>>>>
>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>>>> it here. A bug in the server would be more likely if the problem
>>>>>>> occurs after you restarted the server, but you mention to only
>>>>>>> restart the clients. I mean, even if the server would forget to
>>>>>>> save changes to the database, it would have the most recent ones
>>>>>>> in its cache.
>>>>>>>
>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>> that effect the results.?
>>>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>>>> rather unlikely.
>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>> database (I use the NOOPStore).
>>>>>>> But I've worked many times through all your instructions with a
>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>>>> Server + 2 separate UI clients.
>>>>>>> Not a single sign that something is wrong.
>>>>>>>
>>>>>>> I fear we have only few options:
>>>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>>>> and there)
>>>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>> 4) You have an idea that I didn't have
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102309 is a reply to message #102295] |
Fri, 09 November 2007 14:31 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark Geib schrieb:
> Eike,
>
> I guess I was a bit confused that I could not do anything in the event
> handler that effected the object state. It would seem that I should be
> able to take some action there to handle the event, like doing a
> rollback, etc. I understand that the state machine must control the
> state.
>
> I do have a couple questions.
>
> o Can I tell what objects are deleted in the transaction.?? I can get
> the dirty and new, be not the deleted.
The deleted objects are those with
cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
If you think I should provide a convenience getter in CDOTransaction
please open a feature request for CDO 0.8.
> o Does it make sense to undo my command stack when ever I call
> rollback on a transaction, to keep my GUI consistent with my model
> objects.?? I am still working on this...
No, I don't think so. Undo works but from a CDO framework perspective it
is like the client application, it modifies the objects via normal
EObject API and not via the CDOStore. As a result CDO can't distinguish
between CommandStack access and normal client code access. The
transaction will become dirty. I couldn't find a situation where this is
dangerous for the data but it depends on what you want to achieve.
> o Do you any kind of roadmap for CDO. I am planning to release my
> system using CDO very soon and need some help on when to freeze the
> CDO/Net4J versions. I had planned to use a real release of CDO when I
> do my release so that I do not build and release something slightly
> different than that provided on the eclipse site for CDO.
Hmm, I don't have a written road map and CDO is currrently in a state
where no very obvious things are missing. But I have some ideas and some
are already documented:
https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
Note that a dozen of them or so are already implemented (due to a
problem with the releng infra structure I can't move them to RESOLVED,
Nick is working on that).
Why are asking, do you want to consider some new features or are you
afraid of coming API changes?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
>
> Mark.
>
>
>
> Eike Stepper wrote:
>> Mark,
>>
>> From your writing I get the impression that the cause was in your
>> client code.
>> I must admit that I don't have a clear picture of what was wrong and
>> to what you changed it.
>> If you say it was a silly fault, it's ok for me ;-)
>> If you feel that the CDO API is not clear enough or the wiki could
>> have a FAQ entry to prevent others from running into an open trap,
>> then I'd appreciate if you make it clear with code examples, so that
>> I can publish it.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> OK, I changed my approach with some success.
>>>
>>> Instead of adding the listener and handling the conflict when the
>>> second client saves I now check the transaction in my save method.
>>> If the transaction is dirty and conflicted then I just rollback and
>>> commit. Now everything is useable, that is, I can then re-modify the
>>> objects and do a successful commit from client 1.
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark,
>>>>
>>>> I think this is the root cause. The transaction not being dirty is
>>>> most probably a followup problem because object state CONFLICT
>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>
>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>> RollbackTransition());
>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>
>>>> Please use the Introspector view to verify the state of the
>>>> conflicting objects and the transaction itself before and after the
>>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring
>>>> the transaction in a proper state after commit() and rollback():
>>>>
>>>> public void rollback(boolean remote)
>>>> {
>>>> try
>>>> {
>>>> if (!newResources.isEmpty())
>>>> {
>>>> for (CDOObject newResource : newResources.values())
>>>> {
>>>> removeObject(newResource.cdoID());
>>>> getResourceSet().getResources().remove(newResource);
>>>> }
>>>> }
>>>>
>>>> if (!newObjects.isEmpty())
>>>> {
>>>> for (CDOObject newObject : newObjects.values())
>>>> {
>>>> removeObject(newObject.cdoID());
>>>> }
>>>> }
>>>>
>>>> if (!dirtyObjects.isEmpty())
>>>> {
>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>> {
>>>>
>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>> remote);
>>>> }
>>>> }
>>>>
>>>> cleanUp();
>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>> fireEvent(new
>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>> idMappings));
>>>> }
>>>> catch (RuntimeException ex)
>>>> {
>>>> throw ex;
>>>> }
>>>> catch (Exception ex)
>>>> {
>>>> throw new TransactionException(ex);
>>>> }
>>>> }
>>>>
>>>> private void cleanUp()
>>>> {
>>>> newPackages = null;
>>>> newResources.clear();
>>>> newObjects.clear();
>>>> dirtyObjects.clear();
>>>> dirty = false;
>>>> conflict = false;
>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>> }
>>>>
>>>> BTW. I checked again that all the states have proper values all
>>>> over the process here.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>> not, it's a sign that the problem is in the client. There you can
>>>>>> use the Net4j Container view and the Net4j Introspector view to
>>>>>> click at runtime through the user interface elements down to the
>>>>>> core elements and browse their fields. May be this helps you
>>>>>> track it down further.
>>>>>>
>>>>>> From the log you should be able to locate an appropriate line
>>>>>> for a breakpoint to start debugging at. A high entry could be in
>>>>>> the CommitTransactionAction (if you use that to commit). A low
>>>>>> entry could be CDOTransactionImpl.commit() which is still before
>>>>>> the statemachine for particular objects is triggered.
>>>>>>
>>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>>> something to prepare the old transaction for use again after the
>>>>>>> rollback.??
>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>> should be non-dirty and all objects with newer remote version
>>>>>> should be proxies, all other objects should be clean.
>>>>>>
>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>> That is tests.model1 + CDO UI
>>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>> Mark Geib schrieb:
>>>>>>>>> Eike,
>>>>>>>>>
>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>
>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>> problem. After I do the rollback I can go ahead and modify the
>>>>>>>>> object and a commit succeeds. The problem is that the changes
>>>>>>>>> are not save in the database. That is, if I exit both clients
>>>>>>>>> and then restart only the first saved changes to the object
>>>>>>>>> are present. The changes made after the rollback and re-commit
>>>>>>>>> are lost.
>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>>> for me.
>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>
>>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>>> to) indicate a problem in the client, although I can't
>>>>>>>> reproduce it here. A bug in the server would be more likely if
>>>>>>>> the problem occurs after you restarted the server, but you
>>>>>>>> mention to only restart the clients. I mean, even if the server
>>>>>>>> would forget to save changes to the database, it would have the
>>>>>>>> most recent ones in its cache.
>>>>>>>>
>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>> that effect the results.?
>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>> it's rather unlikely.
>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>> database (I use the NOOPStore).
>>>>>>>> But I've worked many times through all your instructions with a
>>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate
>>>>>>>> CDO Server + 2 separate UI clients.
>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>
>>>>>>>> I fear we have only few options:
>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>> here and there)
>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>> ;-) )
>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eike Stepper
>>>>>>>> ----
>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102322 is a reply to message #102309] |
Fri, 09 November 2007 14:51 |
| Eclipse User |
|
|
|
Eike,
I am only concerned with API changes. I am trying to minimize the risk
of significant changes in a future release, when I want to use some new
feature. This is not a big deal now, just thought I would ask.
Have a good weekend,
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I guess I was a bit confused that I could not do anything in the event
>> handler that effected the object state. It would seem that I should be
>> able to take some action there to handle the event, like doing a
>> rollback, etc. I understand that the state machine must control the
>> state.
>>
>> I do have a couple questions.
>>
>> o Can I tell what objects are deleted in the transaction.?? I can get
>> the dirty and new, be not the deleted.
> The deleted objects are those with
> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>
> If you think I should provide a convenience getter in CDOTransaction
> please open a feature request for CDO 0.8.
>
>> o Does it make sense to undo my command stack when ever I call
>> rollback on a transaction, to keep my GUI consistent with my model
>> objects.?? I am still working on this...
> No, I don't think so. Undo works but from a CDO framework perspective it
> is like the client application, it modifies the objects via normal
> EObject API and not via the CDOStore. As a result CDO can't distinguish
> between CommandStack access and normal client code access. The
> transaction will become dirty. I couldn't find a situation where this is
> dangerous for the data but it depends on what you want to achieve.
>
>> o Do you any kind of roadmap for CDO. I am planning to release my
>> system using CDO very soon and need some help on when to freeze the
>> CDO/Net4J versions. I had planned to use a real release of CDO when I
>> do my release so that I do not build and release something slightly
>> different than that provided on the eclipse site for CDO.
> Hmm, I don't have a written road map and CDO is currrently in a state
> where no very obvious things are missing. But I have some ideas and some
> are already documented:
> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>
>
> Note that a dozen of them or so are already implemented (due to a
> problem with the releng infra structure I can't move them to RESOLVED,
> Nick is working on that).
>
> Why are asking, do you want to consider some new features or are you
> afraid of coming API changes?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>>
>> Mark.
>>
>>
>>
>> Eike Stepper wrote:
>>> Mark,
>>>
>>> From your writing I get the impression that the cause was in your
>>> client code.
>>> I must admit that I don't have a clear picture of what was wrong and
>>> to what you changed it.
>>> If you say it was a silly fault, it's ok for me ;-)
>>> If you feel that the CDO API is not clear enough or the wiki could
>>> have a FAQ entry to prevent others from running into an open trap,
>>> then I'd appreciate if you make it clear with code examples, so that
>>> I can publish it.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> OK, I changed my approach with some success.
>>>>
>>>> Instead of adding the listener and handling the conflict when the
>>>> second client saves I now check the transaction in my save method.
>>>> If the transaction is dirty and conflicted then I just rollback and
>>>> commit. Now everything is useable, that is, I can then re-modify the
>>>> objects and do a successful commit from client 1.
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark,
>>>>>
>>>>> I think this is the root cause. The transaction not being dirty is
>>>>> most probably a followup problem because object state CONFLICT
>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>
>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>> RollbackTransition());
>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>
>>>>> Please use the Introspector view to verify the state of the
>>>>> conflicting objects and the transaction itself before and after the
>>>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring
>>>>> the transaction in a proper state after commit() and rollback():
>>>>>
>>>>> public void rollback(boolean remote)
>>>>> {
>>>>> try
>>>>> {
>>>>> if (!newResources.isEmpty())
>>>>> {
>>>>> for (CDOObject newResource : newResources.values())
>>>>> {
>>>>> removeObject(newResource.cdoID());
>>>>> getResourceSet().getResources().remove(newResource);
>>>>> }
>>>>> }
>>>>>
>>>>> if (!newObjects.isEmpty())
>>>>> {
>>>>> for (CDOObject newObject : newObjects.values())
>>>>> {
>>>>> removeObject(newObject.cdoID());
>>>>> }
>>>>> }
>>>>>
>>>>> if (!dirtyObjects.isEmpty())
>>>>> {
>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>> {
>>>>>
>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>> remote);
>>>>> }
>>>>> }
>>>>>
>>>>> cleanUp();
>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>> fireEvent(new
>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>> idMappings));
>>>>> }
>>>>> catch (RuntimeException ex)
>>>>> {
>>>>> throw ex;
>>>>> }
>>>>> catch (Exception ex)
>>>>> {
>>>>> throw new TransactionException(ex);
>>>>> }
>>>>> }
>>>>>
>>>>> private void cleanUp()
>>>>> {
>>>>> newPackages = null;
>>>>> newResources.clear();
>>>>> newObjects.clear();
>>>>> dirtyObjects.clear();
>>>>> dirty = false;
>>>>> conflict = false;
>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>> }
>>>>>
>>>>> BTW. I checked again that all the states have proper values all
>>>>> over the process here.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>> not, it's a sign that the problem is in the client. There you can
>>>>>>> use the Net4j Container view and the Net4j Introspector view to
>>>>>>> click at runtime through the user interface elements down to the
>>>>>>> core elements and browse their fields. May be this helps you
>>>>>>> track it down further.
>>>>>>>
>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>> for a breakpoint to start debugging at. A high entry could be in
>>>>>>> the CommitTransactionAction (if you use that to commit). A low
>>>>>>> entry could be CDOTransactionImpl.commit() which is still before
>>>>>>> the statemachine for particular objects is triggered.
>>>>>>>
>>>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>>>> something to prepare the old transaction for use again after the
>>>>>>>> rollback.??
>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>
>>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>>> That is tests.model1 + CDO UI
>>>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>> Eike,
>>>>>>>>>>
>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>
>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>> problem. After I do the rollback I can go ahead and modify the
>>>>>>>>>> object and a commit succeeds. The problem is that the changes
>>>>>>>>>> are not save in the database. That is, if I exit both clients
>>>>>>>>>> and then restart only the first saved changes to the object
>>>>>>>>>> are present. The changes made after the rollback and re-commit
>>>>>>>>>> are lost.
>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>>>> for me.
>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>
>>>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>>>> to) indicate a problem in the client, although I can't
>>>>>>>>> reproduce it here. A bug in the server would be more likely if
>>>>>>>>> the problem occurs after you restarted the server, but you
>>>>>>>>> mention to only restart the clients. I mean, even if the server
>>>>>>>>> would forget to save changes to the database, it would have the
>>>>>>>>> most recent ones in its cache.
>>>>>>>>>
>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>> that effect the results.?
>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>> it's rather unlikely.
>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>> But I've worked many times through all your instructions with a
>>>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate
>>>>>>>>> CDO Server + 2 separate UI clients.
>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>
>>>>>>>>> I fear we have only few options:
>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>> here and there)
>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>> ;-) )
>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eike Stepper
>>>>>>>>> ----
>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102335 is a reply to message #102322] |
Fri, 09 November 2007 15:09 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mark,
As my "longest" user I can offer to discuss all API changes with you
before I apply them.
BTW. I'll be on vacation from 11/18 to 12/12, so if you have other
important questions...
Enjoy your weekend, too
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> I am only concerned with API changes. I am trying to minimize the risk
> of significant changes in a future release, when I want to use some
> new feature. This is not a big deal now, just thought I would ask.
>
> Have a good weekend,
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I guess I was a bit confused that I could not do anything in the
>>> event handler that effected the object state. It would seem that I
>>> should be able to take some action there to handle the event, like
>>> doing a rollback, etc. I understand that the state machine must
>>> control the state.
>>>
>>> I do have a couple questions.
>>>
>>> o Can I tell what objects are deleted in the transaction.?? I can
>>> get the dirty and new, be not the deleted.
>> The deleted objects are those with
>> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>>
>> If you think I should provide a convenience getter in CDOTransaction
>> please open a feature request for CDO 0.8.
>>
>>> o Does it make sense to undo my command stack when ever I call
>>> rollback on a transaction, to keep my GUI consistent with my model
>>> objects.?? I am still working on this...
>> No, I don't think so. Undo works but from a CDO framework perspective
>> it is like the client application, it modifies the objects via normal
>> EObject API and not via the CDOStore. As a result CDO can't
>> distinguish between CommandStack access and normal client code
>> access. The transaction will become dirty. I couldn't find a
>> situation where this is dangerous for the data but it depends on what
>> you want to achieve.
>>
>>> o Do you any kind of roadmap for CDO. I am planning to release my
>>> system using CDO very soon and need some help on when to freeze the
>>> CDO/Net4J versions. I had planned to use a real release of CDO when
>>> I do my release so that I do not build and release something
>>> slightly different than that provided on the eclipse site for CDO.
>> Hmm, I don't have a written road map and CDO is currrently in a state
>> where no very obvious things are missing. But I have some ideas and
>> some are already documented:
>> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>>
>>
>> Note that a dozen of them or so are already implemented (due to a
>> problem with the releng infra structure I can't move them to
>> RESOLVED, Nick is working on that).
>>
>> Why are asking, do you want to consider some new features or are you
>> afraid of coming API changes?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>>
>>> Mark.
>>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Mark,
>>>>
>>>> From your writing I get the impression that the cause was in your
>>>> client code.
>>>> I must admit that I don't have a clear picture of what was wrong
>>>> and to what you changed it.
>>>> If you say it was a silly fault, it's ok for me ;-)
>>>> If you feel that the CDO API is not clear enough or the wiki could
>>>> have a FAQ entry to prevent others from running into an open trap,
>>>> then I'd appreciate if you make it clear with code examples, so
>>>> that I can publish it.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> OK, I changed my approach with some success.
>>>>>
>>>>> Instead of adding the listener and handling the conflict when the
>>>>> second client saves I now check the transaction in my save method.
>>>>> If the transaction is dirty and conflicted then I just rollback
>>>>> and commit. Now everything is useable, that is, I can then
>>>>> re-modify the objects and do a successful commit from client 1.
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark,
>>>>>>
>>>>>> I think this is the root cause. The transaction not being dirty
>>>>>> is most probably a followup problem because object state CONFLICT
>>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>>
>>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>>> RollbackTransition());
>>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>>
>>>>>> Please use the Introspector view to verify the state of the
>>>>>> conflicting objects and the transaction itself before and after
>>>>>> the rollback(). The CDOTransactionImpl.cleanUp() method should
>>>>>> bring the transaction in a proper state after commit() and
>>>>>> rollback():
>>>>>>
>>>>>> public void rollback(boolean remote)
>>>>>> {
>>>>>> try
>>>>>> {
>>>>>> if (!newResources.isEmpty())
>>>>>> {
>>>>>> for (CDOObject newResource : newResources.values())
>>>>>> {
>>>>>> removeObject(newResource.cdoID());
>>>>>> getResourceSet().getResources().remove(newResource);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> if (!newObjects.isEmpty())
>>>>>> {
>>>>>> for (CDOObject newObject : newObjects.values())
>>>>>> {
>>>>>> removeObject(newObject.cdoID());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> if (!dirtyObjects.isEmpty())
>>>>>> {
>>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>>> {
>>>>>>
>>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>>> remote);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> cleanUp();
>>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>>> fireEvent(new
>>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>>> idMappings));
>>>>>> }
>>>>>> catch (RuntimeException ex)
>>>>>> {
>>>>>> throw ex;
>>>>>> }
>>>>>> catch (Exception ex)
>>>>>> {
>>>>>> throw new TransactionException(ex);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> private void cleanUp()
>>>>>> {
>>>>>> newPackages = null;
>>>>>> newResources.clear();
>>>>>> newObjects.clear();
>>>>>> dirtyObjects.clear();
>>>>>> dirty = false;
>>>>>> conflict = false;
>>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>>> }
>>>>>>
>>>>>> BTW. I checked again that all the states have proper values all
>>>>>> over the process here.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>> Mark Geib schrieb:
>>>>>>>>> Eike,
>>>>>>>>>
>>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>>> not, it's a sign that the problem is in the client. There you
>>>>>>>> can use the Net4j Container view and the Net4j Introspector
>>>>>>>> view to click at runtime through the user interface elements
>>>>>>>> down to the core elements and browse their fields. May be this
>>>>>>>> helps you track it down further.
>>>>>>>>
>>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>>> for a breakpoint to start debugging at. A high entry could be
>>>>>>>> in the CommitTransactionAction (if you use that to commit). A
>>>>>>>> low entry could be CDOTransactionImpl.commit() which is still
>>>>>>>> before the statemachine for particular objects is triggered.
>>>>>>>>
>>>>>>>>> Do I need to create a new transaction after the rollback, or
>>>>>>>>> do something to prepare the old transaction for use again
>>>>>>>>> after the rollback.??
>>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>>
>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>> Just that we have an indication whether the issue occurs there,
>>>>>>>> too.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eike Stepper
>>>>>>>> ----
>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mark.
>>>>>>>>>
>>>>>>>>> Eike Stepper wrote:
>>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>>> Eike,
>>>>>>>>>>>
>>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>>
>>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>>> problem. After I do the rollback I can go ahead and modify
>>>>>>>>>>> the object and a commit succeeds. The problem is that the
>>>>>>>>>>> changes are not save in the database. That is, if I exit
>>>>>>>>>>> both clients and then restart only the first saved changes
>>>>>>>>>>> to the object are present. The changes made after the
>>>>>>>>>>> rollback and re-commit are lost.
>>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>>> But I double checked your "new" scenario and it works
>>>>>>>>>> perfectly for me.
>>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>>
>>>>>>>>>> Another thought: What you describe here could (but doesn't
>>>>>>>>>> need to) indicate a problem in the client, although I can't
>>>>>>>>>> reproduce it here. A bug in the server would be more likely
>>>>>>>>>> if the problem occurs after you restarted the server, but you
>>>>>>>>>> mention to only restart the clients. I mean, even if the
>>>>>>>>>> server would forget to save changes to the database, it would
>>>>>>>>>> have the most recent ones in its cache.
>>>>>>>>>>
>>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>>> that effect the results.?
>>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>>> it's rather unlikely.
>>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>>> But I've worked many times through all your instructions with
>>>>>>>>>> a proper 4 process setup: Separate db (Derby+HSQLDB),
>>>>>>>>>> separate CDO Server + 2 separate UI clients.
>>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>>
>>>>>>>>>> I fear we have only few options:
>>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>>> here and there)
>>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>>> ;-) )
>>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Eike Stepper
>>>>>>>>>> ----
>>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #102350 is a reply to message #102335] |
Fri, 09 November 2007 15:09 |
| Eclipse User |
|
|
|
Eike,
Thanks for the info. Knowing that I will plan to have a release done by
the end of the day on the 17th, well the 16th.
Also, thanks for the offer regarding API changes, but no need for that.
Mark.
Eike Stepper wrote:
> Mark,
>
> As my "longest" user I can offer to discuss all API changes with you
> before I apply them.
> BTW. I'll be on vacation from 11/18 to 12/12, so if you have other
> important questions...
>
> Enjoy your weekend, too
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I am only concerned with API changes. I am trying to minimize the risk
>> of significant changes in a future release, when I want to use some
>> new feature. This is not a big deal now, just thought I would ask.
>>
>> Have a good weekend,
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I guess I was a bit confused that I could not do anything in the
>>>> event handler that effected the object state. It would seem that I
>>>> should be able to take some action there to handle the event, like
>>>> doing a rollback, etc. I understand that the state machine must
>>>> control the state.
>>>>
>>>> I do have a couple questions.
>>>>
>>>> o Can I tell what objects are deleted in the transaction.?? I can
>>>> get the dirty and new, be not the deleted.
>>> The deleted objects are those with
>>> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>>>
>>> If you think I should provide a convenience getter in CDOTransaction
>>> please open a feature request for CDO 0.8.
>>>
>>>> o Does it make sense to undo my command stack when ever I call
>>>> rollback on a transaction, to keep my GUI consistent with my model
>>>> objects.?? I am still working on this...
>>> No, I don't think so. Undo works but from a CDO framework perspective
>>> it is like the client application, it modifies the objects via normal
>>> EObject API and not via the CDOStore. As a result CDO can't
>>> distinguish between CommandStack access and normal client code
>>> access. The transaction will become dirty. I couldn't find a
>>> situation where this is dangerous for the data but it depends on what
>>> you want to achieve.
>>>
>>>> o Do you any kind of roadmap for CDO. I am planning to release my
>>>> system using CDO very soon and need some help on when to freeze the
>>>> CDO/Net4J versions. I had planned to use a real release of CDO when
>>>> I do my release so that I do not build and release something
>>>> slightly different than that provided on the eclipse site for CDO.
>>> Hmm, I don't have a written road map and CDO is currrently in a state
>>> where no very obvious things are missing. But I have some ideas and
>>> some are already documented:
>>> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>>>
>>>
>>> Note that a dozen of them or so are already implemented (due to a
>>> problem with the releng infra structure I can't move them to
>>> RESOLVED, Nick is working on that).
>>>
>>> Why are asking, do you want to consider some new features or are you
>>> afraid of coming API changes?
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>>>
>>>> Mark.
>>>>
>>>>
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark,
>>>>>
>>>>> From your writing I get the impression that the cause was in your
>>>>> client code.
>>>>> I must admit that I don't have a clear picture of what was wrong
>>>>> and to what you changed it.
>>>>> If you say it was a silly fault, it's ok for me ;-)
>>>>> If you feel that the CDO API is not clear enough or the wiki could
>>>>> have a FAQ entry to prevent others from running into an open trap,
>>>>> then I'd appreciate if you make it clear with code examples, so
>>>>> that I can publish it.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>>
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> OK, I changed my approach with some success.
>>>>>>
>>>>>> Instead of adding the listener and handling the conflict when the
>>>>>> second client saves I now check the transaction in my save method.
>>>>>> If the transaction is dirty and conflicted then I just rollback
>>>>>> and commit. Now everything is useable, that is, I can then
>>>>>> re-modify the objects and do a successful commit from client 1.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark,
>>>>>>>
>>>>>>> I think this is the root cause. The transaction not being dirty
>>>>>>> is most probably a followup problem because object state CONFLICT
>>>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>>>
>>>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>>>> RollbackTransition());
>>>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>>>
>>>>>>> Please use the Introspector view to verify the state of the
>>>>>>> conflicting objects and the transaction itself before and after
>>>>>>> the rollback(). The CDOTransactionImpl.cleanUp() method should
>>>>>>> bring the transaction in a proper state after commit() and
>>>>>>> rollback():
>>>>>>>
>>>>>>> public void rollback(boolean remote)
>>>>>>> {
>>>>>>> try
>>>>>>> {
>>>>>>> if (!newResources.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject newResource : newResources.values())
>>>>>>> {
>>>>>>> removeObject(newResource.cdoID());
>>>>>>> getResourceSet().getResources().remove(newResource);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> if (!newObjects.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject newObject : newObjects.values())
>>>>>>> {
>>>>>>> removeObject(newObject.cdoID());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> if (!dirtyObjects.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>>>> {
>>>>>>>
>>>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>>>> remote);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> cleanUp();
>>>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>>>> fireEvent(new
>>>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>>>> idMappings));
>>>>>>> }
>>>>>>> catch (RuntimeException ex)
>>>>>>> {
>>>>>>> throw ex;
>>>>>>> }
>>>>>>> catch (Exception ex)
>>>>>>> {
>>>>>>> throw new TransactionException(ex);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> private void cleanUp()
>>>>>>> {
>>>>>>> newPackages = null;
>>>>>>> newResources.clear();
>>>>>>> newObjects.clear();
>>>>>>> dirtyObjects.clear();
>>>>>>> dirty = false;
>>>>>>> conflict = false;
>>>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>>>> }
>>>>>>>
>>>>>>> BTW. I checked again that all the states have proper values all
>>>>>>> over the process here.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>> Eike,
>>>>>>>>>>
>>>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>>>> not, it's a sign that the problem is in the client. There you
>>>>>>>>> can use the Net4j Container view and the Net4j Introspector
>>>>>>>>> view to click at runtime through the user interface elements
>>>>>>>>> down to the core elements and browse their fields. May be this
>>>>>>>>> helps you track it down further.
>>>>>>>>>
>>>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>>>> for a breakpoint to start debugging at. A high entry could be
>>>>>>>>> in the CommitTransactionAction (if you use that to commit). A
>>>>>>>>> low entry could be CDOTransactionImpl.commit() which is still
>>>>>>>>> before the statemachine for particular objects is triggered.
>>>>>>>>>
>>>>>>>>>> Do I need to create a new transaction after the rollback, or
>>>>>>>>>> do something to prepare the old transaction for use again
>>>>>>>>>> after the rollback.??
>>>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>>>
>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>> Just that we have an indication whether the issue occurs there,
>>>>>>>>> too.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eike Stepper
>>>>>>>>> ----
>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mark.
>>>>>>>>>>
>>>>>>>>>> Eike Stepper wrote:
>>>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>>>> Eike,
>>>>>>>>>>>>
>>>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>>>
>>>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>>>> problem. After I do the rollback I can go ahead and modify
>>>>>>>>>>>> the object and a commit succeeds. The problem is that the
>>>>>>>>>>>> changes are not save in the database. That is, if I exit
>>>>>>>>>>>> both clients and then restart only the first saved changes
>>>>>>>>>>>> to the object are present. The changes made after the
>>>>>>>>>>>> rollback and re-commit are lost.
>>>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>>>> But I double checked your "new" scenario and it works
>>>>>>>>>>> perfectly for me.
>>>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>>>
>>>>>>>>>>> Another thought: What you describe here could (but doesn't
>>>>>>>>>>> need to) indicate a problem in the client, although I can't
>>>>>>>>>>> reproduce it here. A bug in the server would be more likely
>>>>>>>>>>> if the problem occurs after you restarted the server, but you
>>>>>>>>>>> mention to only restart the clients. I mean, even if the
>>>>>>>>>>> server would forget to save changes to the database, it would
>>>>>>>>>>> have the most recent ones in its cache.
>>>>>>>>>>>
>>>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>>>> that effect the results.?
>>>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>>>> it's rather unlikely.
>>>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>>>> But I've worked many times through all your instructions with
>>>>>>>>>>> a proper 4 process setup: Separate db (Derby+HSQLDB),
>>>>>>>>>>> separate CDO Server + 2 separate UI clients.
>>>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>>>
>>>>>>>>>>> I fear we have only few options:
>>>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>>>> here and there)
>>>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>>>> ;-) )
>>>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Eike Stepper
>>>>>>>>>>> ----
>>>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610284 is a reply to message #100873] |
Wed, 07 November 2007 10:14 |
| Eclipse User |
|
|
|
Mark,
There is a Rollback... entry on the transaction's context menu in the
CDO Sessions view.
I've just committed two changes:
1) CDOTransaction API has now a boolean remote parameter on the
rollback() method.
Remote rollback will rollback the transaction to reflect the latest
*remote* state.
Local rollback will rollback the transaction to reflect the latest
*local* state. This is not dangerous but can lead to undesired local
effects when the conflicting object is edited and committed later!
2) The RollbackTransactionDialog now appears after a version conflict is
detected on save.
I guess now it'smore obvious what to do ;-)
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> I have the invalidation notifications working now. But now I need to be
> able to handle the case where user A modifies an object, but does not
> save, then user B modified and saves the same object. When user A
> finally does a save he gets an error that says the version is a
> duplicate, which makes sense.
>
> How do I handle this case in my client with user A losing his work. Can
> I refresh the objects so that he can save..?
>
> Mark.
>
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610290 is a reply to message #101125] |
Wed, 07 November 2007 15:17 |
| Eclipse User |
|
|
|
Eike,
I have playing with the rollback for awhile now and I don't see what I
expect.
I have two clients running. In client #1 I modify an object but do not
save/commit. In client #2 I modify the same object and save. When the
save on client #2 occurs I receive an event CDOTransactionConflictEvent
in client #1. When I receive that event I do a rollback(true) and the
object reverts to the remote version PRIOR to the save on client #2, so
now the object looks like it did before ANY modifications. At this point
I can do more changes and saves in client #2 with no problem, but
nothing I do in client #1 will cause changes to be saved. It is as
though the object in client #1 is invalid for ever after the conflict.
So, how do I get the object in client #1 in a state that it can be
used...
Mark.
On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> Mark,
>
> There is a Rollback... entry on the transaction's context menu in the
> CDO Sessions view.
> I've just committed two changes:
>
> 1) CDOTransaction API has now a boolean remote parameter on the
> rollback() method.
> Remote rollback will rollback the transaction to reflect the latest
> *remote* state.
> Local rollback will rollback the transaction to reflect the latest
> *local* state. This is not dangerous but can lead to undesired local
> effects when the conflicting object is edited and committed later!
>
> 2) The RollbackTransactionDialog now appears after a version conflict is
> detected on save.
>
> I guess now it'smore obvious what to do ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
> > Eike,
> >
> > I have the invalidation notifications working now. But now I need to be
> > able to handle the case where user A modifies an object, but does not
> > save, then user B modified and saves the same object. When user A
> > finally does a save he gets an error that says the version is a
> > duplicate, which makes sense.
> >
> > How do I handle this case in my client with user A losing his work. Can
> > I refresh the objects so that he can save..?
> >
> > Mark.
> >
> >
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610291 is a reply to message #101208] |
Wed, 07 November 2007 15:59 |
| Eclipse User |
|
|
|
Eike,
Some more information here may help.
The situation I need to handle is when, in production, two different
users modify large numbers of objects, say 10s or 100s over some
significant time. They may have a single object common to each users set
of modified objects. When they go to save what may be an hour of work
one of them, the last in this case, loses all their work. The database
is consistent, but there is loss of work. I need to be able to recover
the conflicted client to state that a save/commit will succeed.
Mark.
On Wed, 2007-11-07 at 13:17 -0700, Mark Geib wrote:
> Eike,
>
> I have playing with the rollback for awhile now and I don't see what I
> expect.
>
> I have two clients running. In client #1 I modify an object but do not
> save/commit. In client #2 I modify the same object and save. When the
> save on client #2 occurs I receive an event CDOTransactionConflictEvent
> in client #1. When I receive that event I do a rollback(true) and the
> object reverts to the remote version PRIOR to the save on client #2, so
> now the object looks like it did before ANY modifications. At this point
> I can do more changes and saves in client #2 with no problem, but
> nothing I do in client #1 will cause changes to be saved. It is as
> though the object in client #1 is invalid for ever after the conflict.
>
> So, how do I get the object in client #1 in a state that it can be
> used...
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> > Mark,
> >
> > There is a Rollback... entry on the transaction's context menu in the
> > CDO Sessions view.
> > I've just committed two changes:
> >
> > 1) CDOTransaction API has now a boolean remote parameter on the
> > rollback() method.
> > Remote rollback will rollback the transaction to reflect the latest
> > *remote* state.
> > Local rollback will rollback the transaction to reflect the latest
> > *local* state. This is not dangerous but can lead to undesired local
> > effects when the conflicting object is edited and committed later!
> >
> > 2) The RollbackTransactionDialog now appears after a version conflict is
> > detected on save.
> >
> > I guess now it'smore obvious what to do ;-)
> >
> > Regards,
> > Eike Stepper
> > ----
> > http://wiki.eclipse.org/?title=CDO
> > http://wiki.eclipse.org/?title=Net4j
> >
> >
> >
> > Mark Geib schrieb:
> > > Eike,
> > >
> > > I have the invalidation notifications working now. But now I need to be
> > > able to handle the case where user A modifies an object, but does not
> > > save, then user B modified and saves the same object. When user A
> > > finally does a save he gets an error that says the version is a
> > > duplicate, which makes sense.
> > >
> > > How do I handle this case in my client with user A losing his work. Can
> > > I refresh the objects so that he can save..?
> > >
> > > Mark.
> > >
> > >
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610292 is a reply to message #101208] |
Wed, 07 November 2007 16:28 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------030700050005090001060008
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mark Geib schrieb:
> Eike,
>
> I have playing with the rollback for awhile now and I don't see what I
> expect.
>
> I have two clients running. In client #1 I modify an object but do not
> save/commit. In client #2 I modify the same object and save. When the
> save on client #2 occurs I receive an event CDOTransactionConflictEvent
> in client #1. When I receive that event I do a rollback(true) and the
> object reverts to the remote version PRIOR to the save on client #2, so
> now the object looks like it did before ANY modifications.
That's not what happens here.
The conflicting object in client #1 reverts to the version client #2 has
committed.
Could you please try a CVS update.
Recently I experienced delays in the CVS mirrors.
May be you don't have the most recent version?!
If the misbehaviour persists I need to know more about your clients.
You don't use the CDOEditor?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
> At this point
> I can do more changes and saves in client #2 with no problem, but
> nothing I do in client #1 will cause changes to be saved. It is as
> though the object in client #1 is invalid for ever after the conflict.
>
> So, how do I get the object in client #1 in a state that it can be
> used...
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>
>> Mark,
>>
>> There is a Rollback... entry on the transaction's context menu in the
>> CDO Sessions view.
>> I've just committed two changes:
>>
>> 1) CDOTransaction API has now a boolean remote parameter on the
>> rollback() method.
>> Remote rollback will rollback the transaction to reflect the latest
>> *remote* state.
>> Local rollback will rollback the transaction to reflect the latest
>> *local* state. This is not dangerous but can lead to undesired local
>> effects when the conflicting object is edited and committed later!
>>
>> 2) The RollbackTransactionDialog now appears after a version conflict is
>> detected on save.
>>
>> I guess now it'smore obvious what to do ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have the invalidation notifications working now. But now I need to be
>>> able to handle the case where user A modifies an object, but does not
>>> save, then user B modified and saves the same object. When user A
>>> finally does a save he gets an error that says the version is a
>>> duplicate, which makes sense.
>>>
>>> How do I handle this case in my client with user A losing his work. Can
>>> I refresh the objects so that he can save..?
>>>
>>> Mark.
>>>
>>>
>>>
>
>
--------------030700050005090001060008
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Mark Geib schrieb:
<blockquote cite="mid:1194466661.883.6.camel@dhcp07-gr.dev.uplink"
type="cite">
<pre wrap="">Eike,
I have playing with the rollback for awhile now and I don't see what I
expect.
I have two clients running. In client #1 I modify an object but do not
save/commit. In client #2 I modify the same object and save. When the
save on client #2 occurs I receive an event CDOTransactionConflictEvent
in client #1. When I receive that event I do a rollback(true) and the
object reverts to the remote version PRIOR to the save on client #2, so
now the object looks like it did before ANY modifications. </pre>
</blockquote>
That's not what happens here.<br>
The conflicting object in client #1 reverts to the version client #2
has committed.<br>
<br>
Could you please try a CVS update. <br>
Recently I experienced delays in the CVS mirrors. <br>
May be you don't have the most recent version?!<br>
<br>
If the misbehaviour persists I need to know more about your clients.<br>
You don't use the CDOEditor?<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=CDO">http://wiki.eclipse.org/?title=CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=Net4j">http://wiki.eclipse.org/?title=Net4j</a><br>
<br>
<br>
<blockquote cite="mid:1194466661.883.6.camel@dhcp07-gr.dev.uplink"
type="cite">
<pre wrap="">At this point
I can do more changes and saves in client #2 with no problem, but
nothing I do in client #1 will cause changes to be saved. It is as
though the object in client #1 is invalid for ever after the conflict.
So, how do I get the object in client #1 in a state that it can be
used...
Mark.
On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Mark,
There is a Rollback... entry on the transaction's context menu in the
CDO Sessions view.
I've just committed two changes:
1) CDOTransaction API has now a boolean remote parameter on the
rollback() method.
Remote rollback will rollback the transaction to reflect the latest
*remote* state.
Local rollback will rollback the transaction to reflect the latest
*local* state. This is not dangerous but can lead to undesired local
effects when the conflicting object is edited and committed later!
2) The RollbackTransactionDialog now appears after a version conflict is
detected on save.
I guess now it'smore obvious what to do ;-)
Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=CDO">http://wiki.eclipse.org/?title=CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/?title=Net4j">http://wiki.eclipse.org/?title=Net4j</a>
Mark Geib schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Eike,
I have the invalidation notifications working now. But now I need to be
able to handle the case where user A modifies an object, but does not
save, then user B modified and saves the same object. When user A
finally does a save he gets an error that says the version is a
duplicate, which makes sense.
How do I handle this case in my client with user A losing his work. Can
I refresh the objects so that he can save..?
Mark.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
--------------030700050005090001060008--
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610293 is a reply to message #101238] |
Wed, 07 November 2007 16:34 |
| Eclipse User |
|
|
|
Eike,
In my handler for the CDOTransactionConflictEvent event I call
transaction.rollback(true) and I get the version of the object prior to
any changes. If I call
CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
I don't use the CDOEditor at all. I could for testing, but my client is
very graphical, and in fact some of the objects in my model are the
graphical locations of the objects as well as the links between objects.
The use a tree based editor is fairly limited for my model.
Mark.
On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
> Mark Geib schrieb:
> > Eike,
> >
> > I have playing with the rollback for awhile now and I don't see what I
> > expect.
> >
> > I have two clients running. In client #1 I modify an object but do not
> > save/commit. In client #2 I modify the same object and save. When the
> > save on client #2 occurs I receive an event CDOTransactionConflictEvent
> > in client #1. When I receive that event I do a rollback(true) and the
> > object reverts to the remote version PRIOR to the save on client #2, so
> > now the object looks like it did before ANY modifications.
> That's not what happens here.
> The conflicting object in client #1 reverts to the version client #2
> has committed.
>
> Could you please try a CVS update.
> Recently I experienced delays in the CVS mirrors.
> May be you don't have the most recent version?!
>
> If the misbehaviour persists I need to know more about your clients.
> You don't use the CDOEditor?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> > At this point
> > I can do more changes and saves in client #2 with no problem, but
> > nothing I do in client #1 will cause changes to be saved. It is as
> > though the object in client #1 is invalid for ever after the conflict.
> >
> > So, how do I get the object in client #1 in a state that it can be
> > used...
> >
> > Mark.
> >
> >
> >
> > On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
> >
> > > Mark,
> > >
> > > There is a Rollback... entry on the transaction's context menu in the
> > > CDO Sessions view.
> > > I've just committed two changes:
> > >
> > > 1) CDOTransaction API has now a boolean remote parameter on the
> > > rollback() method.
> > > Remote rollback will rollback the transaction to reflect the latest
> > > *remote* state.
> > > Local rollback will rollback the transaction to reflect the latest
> > > *local* state. This is not dangerous but can lead to undesired local
> > > effects when the conflicting object is edited and committed later!
> > >
> > > 2) The RollbackTransactionDialog now appears after a version conflict is
> > > detected on save.
> > >
> > > I guess now it'smore obvious what to do ;-)
> > >
> > > Regards,
> > > Eike Stepper
> > > ----
> > > http://wiki.eclipse.org/?title=CDO
> > > http://wiki.eclipse.org/?title=Net4j
> > >
> > >
> > >
> > > Mark Geib schrieb:
> > >
> > > > Eike,
> > > >
> > > > I have the invalidation notifications working now. But now I need to be
> > > > able to handle the case where user A modifies an object, but does not
> > > > save, then user B modified and saves the same object. When user A
> > > > finally does a save he gets an error that says the version is a
> > > > duplicate, which makes sense.
> > > >
> > > > How do I handle this case in my client with user A losing his work. Can
> > > > I refresh the objects so that he can save..?
> > > >
> > > > Mark.
> > > >
> > > >
> > > >
> >
> >
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610299 is a reply to message #101247] |
Thu, 08 November 2007 02:33 |
| Eclipse User |
|
|
|
Mark Geib schrieb:
> Eike,
>
> In my handler for the CDOTransactionConflictEvent event I call
> transaction.rollback(true) and I get the version of the object prior to
> any changes. If I call
> CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
>
Some comments on the state machine call:
1) It should work but it is internal API. I'm currently working on a
public CDOObject.cdoRefresh(boolean force). Until then it you should
achieve the same effect (without force) by calling any non-transient
getter on the object.
2) The server stops to commit the transaction on the first conflict, so
the event possibly doesn't contain all conflicting objects. Rolling back
the client transaction to remote state in fact turns all modified
objects into proxies. the next access (if any) will reload the object
from the server.
I tested once more here and everything is working as expected.
Particularly the scenario you describe:
client1: open session
client1: register model
client1: open transaction
client1: create resource
client1: add object X
client1: save
client2: open session
client2: open transaction
client2: load resource
client2: modify object X.name = "B"
client1: modify object X.name = "A"
client1: save
client2: shows conflict on object X
client2: save
client2: opens transaction error dialog
client2: rollback to remote state
client2: show object X.name = "A"
client2: modify object X.name = "C"
client2: save
client2: show object X.name = "C"
client1: show object X.name = "C"
> I don't use the CDOEditor at all. I could for testing, but my client is
> very graphical, and in fact some of the objects in my model are the
> graphical locations of the objects as well as the links between objects.
> The use a tree based editor is fairly limited for my model.
>
Sounds interesting!
The specified ehaviour should of course be independent of the client
application, be it a UI or a batch.
I'll provide a standalone test case so that you can better compare with
your scenario...
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
> Mark.
>
>
>
> On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have playing with the rollback for awhile now and I don't see what I
>>> expect.
>>>
>>> I have two clients running. In client #1 I modify an object but do not
>>> save/commit. In client #2 I modify the same object and save. When the
>>> save on client #2 occurs I receive an event CDOTransactionConflictEvent
>>> in client #1. When I receive that event I do a rollback(true) and the
>>> object reverts to the remote version PRIOR to the save on client #2, so
>>> now the object looks like it did before ANY modifications.
>>>
>> That's not what happens here.
>> The conflicting object in client #1 reverts to the version client #2
>> has committed.
>>
>> Could you please try a CVS update.
>> Recently I experienced delays in the CVS mirrors.
>> May be you don't have the most recent version?!
>>
>> If the misbehaviour persists I need to know more about your clients.
>> You don't use the CDOEditor?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>> At this point
>>> I can do more changes and saves in client #2 with no problem, but
>>> nothing I do in client #1 will cause changes to be saved. It is as
>>> though the object in client #1 is invalid for ever after the conflict.
>>>
>>> So, how do I get the object in client #1 in a state that it can be
>>> used...
>>>
>>> Mark.
>>>
>>>
>>>
>>> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>>>
>>>
>>>> Mark,
>>>>
>>>> There is a Rollback... entry on the transaction's context menu in the
>>>> CDO Sessions view.
>>>> I've just committed two changes:
>>>>
>>>> 1) CDOTransaction API has now a boolean remote parameter on the
>>>> rollback() method.
>>>> Remote rollback will rollback the transaction to reflect the latest
>>>> *remote* state.
>>>> Local rollback will rollback the transaction to reflect the latest
>>>> *local* state. This is not dangerous but can lead to undesired local
>>>> effects when the conflicting object is edited and committed later!
>>>>
>>>> 2) The RollbackTransactionDialog now appears after a version conflict is
>>>> detected on save.
>>>>
>>>> I guess now it'smore obvious what to do ;-)
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>
>>>>
>>>>> Eike,
>>>>>
>>>>> I have the invalidation notifications working now. But now I need to be
>>>>> able to handle the case where user A modifies an object, but does not
>>>>> save, then user B modified and saves the same object. When user A
>>>>> finally does a save he gets an error that says the version is a
>>>>> duplicate, which makes sense.
>>>>>
>>>>> How do I handle this case in my client with user A losing his work. Can
>>>>> I refresh the objects so that he can save..?
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610458 is a reply to message #101247] |
Thu, 08 November 2007 03:17 |
| Eclipse User |
|
|
|
This is a multi-part message in MIME format.
--------------090901010402030505080407
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mark,
With the following test case (update cdo and cdo.tests) I can proof that
it's working standalone.
The flow1() method mimics exactly the same flow that I described in the
other reply.
The log output of the tests is attached.
public class RollbackTest extends AbstractCDOTest
{
public void testRollbackSameSession() throws Exception
{
CDOSession session = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session.getPackageRegistry().putEPackage(Model1Package.eINST ANCE);
CDOTransaction transaction1 = session.openTransaction();
CDOTransaction transaction2 = session.openTransaction();
flow1(transaction1, transaction2);
}
public void testRollbackSeparateSession() throws Exception
{
// Client1
CDOSession session1 = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session1.getPackageRegistry().putEPackage(Model1Package.eINS TANCE);
CDOTransaction transaction1 = session1.openTransaction();
// Client2
CDOSession session2 = CDOUtil.openSession(getConnector(),
REPOSITORY_NAME);
session2.getPackageRegistry().putEPackage(Model1Package.eINS TANCE);
CDOTransaction transaction2 = session2.openTransaction();
flow1(transaction1, transaction2);
}
protected void flow1(CDOTransaction transaction1, CDOTransaction
transaction2)
{
// Client1
CDOResource resource1 = transaction1.createResource("/test1");
Company company1 = Model1Factory.eINSTANCE.createCompany();
resource1.getContents().add(company1);
Category category1 = Model1Factory.eINSTANCE.createCategory();
company1.getCategories().add(category1);
transaction1.commit();
// Client2
CDOResource resource2 = transaction2.getResource("/test1");
Company company2 = (Company)resource2.getContents().get(0);
Category category2 = company2.getCategories().get(0);
category2.setName("client2");
// Client1
category1.setName("client1");
transaction1.commit();
sleep(500);
// Client2
assertEquals(true, transaction2.isDirty());
assertEquals(true, transaction2.hasConflict());
try
{
transaction2.commit();
fail("Commit on transaction2 should fail");
}
catch (TransactionException ex)
{
transaction2.rollback(true);
}
assertEquals(false, transaction2.isDirty());
assertEquals(false, transaction2.hasConflict());
assertEquals("client1", category2.getName());
category2.setName("client2");
transaction2.commit();
assertEquals(false, transaction2.isDirty());
assertEquals(false, transaction2.hasConflict());
assertEquals("client2", category2.getName());
sleep(500);
// Client1
assertEquals(false, transaction1.isDirty());
assertEquals(false, transaction1.hasConflict());
assertEquals("client2", category1.getName());
}
}
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> In my handler for the CDOTransactionConflictEvent event I call
> transaction.rollback(true) and I get the version of the object prior to
> any changes. If I call
> CDOStateMachine.INSTANCE.read((InternalCDOObject)e.getConfli ctingObject()) I then get the version saved/committed by client #2. However, I can not ever save/commit that object again in client #1.
>
> I don't use the CDOEditor at all. I could for testing, but my client is
> very graphical, and in fact some of the objects in my model are the
> graphical locations of the objects as well as the links between objects.
> The use a tree based editor is fairly limited for my model.
>
> Mark.
>
>
>
> On Wed, 2007-11-07 at 22:28 +0100, Eike Stepper wrote:
>
>> Mark Geib schrieb:
>>
>>> Eike,
>>>
>>> I have playing with the rollback for awhile now and I don't see what I
>>> expect.
>>>
>>> I have two clients running. In client #1 I modify an object but do not
>>> save/commit. In client #2 I modify the same object and save. When the
>>> save on client #2 occurs I receive an event CDOTransactionConflictEvent
>>> in client #1. When I receive that event I do a rollback(true) and the
>>> object reverts to the remote version PRIOR to the save on client #2, so
>>> now the object looks like it did before ANY modifications.
>>>
>> That's not what happens here.
>> The conflicting object in client #1 reverts to the version client #2
>> has committed.
>>
>> Could you please try a CVS update.
>> Recently I experienced delays in the CVS mirrors.
>> May be you don't have the most recent version?!
>>
>> If the misbehaviour persists I need to know more about your clients.
>> You don't use the CDOEditor?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>> At this point
>>> I can do more changes and saves in client #2 with no problem, but
>>> nothing I do in client #1 will cause changes to be saved. It is as
>>> though the object in client #1 is invalid for ever after the conflict.
>>>
>>> So, how do I get the object in client #1 in a state that it can be
>>> used...
>>>
>>> Mark.
>>>
>>>
>>>
>>> On Wed, 2007-11-07 at 16:14 +0100, Eike Stepper wrote:
>>>
>>>
>>>> Mark,
>>>>
>>>> There is a Rollback... entry on the transaction's context menu in the
>>>> CDO Sessions view.
>>>> I've just committed two changes:
>>>>
>>>> 1) CDOTransaction API has now a boolean remote parameter on the
>>>> rollback() method.
>>>> Remote rollback will rollback the transaction to reflect the latest
>>>> *remote* state.
>>>> Local rollback will rollback the transaction to reflect the latest
>>>> *local* state. This is not dangerous but can lead to undesired local
>>>> effects when the conflicting object is edited and committed later!
>>>>
>>>> 2) The RollbackTransactionDialog now appears after a version conflict is
>>>> detected on save.
>>>>
>>>> I guess now it'smore obvious what to do ;-)
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>
>>>>
>>>>> Eike,
>>>>>
>>>>> I have the invalidation notifications working now. But now I need to be
>>>>> able to handle the case where user A modifies an object, but does not
>>>>> save, then user B modified and saves the same object. When user A
>>>>> finally does a save he gets an error that says the version is a
>>>>> duplicate, which makes sense.
>>>>>
>>>>> How do I handle this case in my client with user A losing his work. Can
>>>>> I refresh the objects so that he can save..?
>>>>>
>>>>> Mark.
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--------------090901010402030505080407
Content-Type: text/x-log;
name="rollback.log"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
filename="rollback.log"
************************************************
testRollbackSameSession
************************************************
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=3Dnull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRan=
ge=3Dnull)
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, metaIDRange=3Dn=
ull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOResource)
main [CDOFeatureImpl] Created CDOFeature(ID=3D8, name=3Dpath, type=3DSTRI=
NG, referenceType=3Dnull)
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D8, name=3Dpath, type=3D=
STRING, referenceType=3Dnull)
main [CDOFeatureImpl] Created CDOFeature(ID=3D2, name=3Dcontents, type=3D=
OBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D2, name=3Dcontents, t=
ype=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOResource)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, m=
etaIDRange=3Dnull)
main [Lifecycle] Activating Repository[repo1, null]
main [Lifecycle] Activating NOOPStore@1
main [Lifecycle] DUMP NOOPStore@1
Store.type =3D noop
Store.repository =3D Repository[repo1, null]
Store.nextOIDValue =3D 2
main [Lifecycle] Activating TypeManager@2
main [Lifecycle] DUMP TypeManager@2
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@1be0f0a[C=
ount =3D 0]
Worker.workerThread =3D Thread[Thread-0,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
repository =3D Repository[repo1, null]
persistent =3D false
objectTypes =3D=20
packageURIMap =3D null
packageIDMap =3D null
objectTypeMap =3D null
metaObjectTypeMap =3D null
nextPackageID =3D 0
main [Lifecycle] Activating PackageManager@3
main [Lifecycle] DUMP PackageManager@3
CDOPackageManagerImpl.packages =3D=20
http://www.eclipse.org/emf/CDO/core/1.0.0=3DCDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull)
http://www.eclipse.org/emf/CDO/resource/1.0.0=3DCDOPackage(URI=3Dhttp=
://www.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3D=
false, metaIDRange=3Dnull)
CDOPackageManagerImpl.cdoCorePackage =3D CDOPackage(URI=3Dhttp://www.ecl=
ipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=
=3Dnull)
CDOPackageManagerImpl.cdoResourcePackage =3D CDOPackage(URI=3Dhttp://www=
=2Eeclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull)
repository =3D Repository[repo1, null]
main [Lifecycle] Activating SessionManager@4
main [Lifecycle] DUMP SessionManager@4
repository =3D Repository[repo1, null]
sessions =3D=20
lastSessionID =3D 0
main [Lifecycle] Activating ResourceManager@5
main [Lifecycle] DUMP ResourceManager@5
repository =3D Repository[repo1, null]
idToPathMap =3D=20
pathToIDMap =3D=20
main [Lifecycle] Activating RevisionManager@6
main [Lifecycle] DUMP RevisionManager@6
CDORevisionResolverImpl.revisions =3D=20
CDORevisionResolverImpl.currentLRUCapacity =3D 0
CDORevisionResolverImpl.revisedLRUCapacity =3D 0
CDORevisionResolverImpl.currentLRU =3D LRU[size=3D0, capacity=3D0]
CDORevisionResolverImpl.revisedLRU =3D LRU[size=3D0, capacity=3D0]
repository =3D Repository[repo1, null]
cdoPathFeature =3D CDOFeature(ID=3D8, name=3Dpath, type=3DSTRING, refere=
nceType=3Dnull)
main [Lifecycle] DUMP Repository@7
name =3D repo1
store =3D NOOPStore@1
uuid =3D null
properties =3D=20
supportingAudits =3D false
verifyingRevisions =3D null
rememberingKnownTypes =3D null
typeManager =3D TypeManager@2
packageManager =3D PackageManager@3
sessionManager =3D SessionManager@4
resourceManager =3D ResourceManager@5
revisionManager =3D RevisionManager@6
elements =3D [Lorg.eclipse.emf.cdo.server.IRepositoryElement;@1275d39
nextMetaIDValue =3D 1
main [Lifecycle] Activating ManagedContainer
main [Lifecycle] Activating {org.eclipse.net4j.connectors[tcp]=3DFactory[=
org.eclipse.net4j.connectors, tcp], org.eclipse.net4j.randomizers[default=
]=3DFactory[org.eclipse.net4j.randomizers, default], org.eclipse.net4j.cl=
ientProtocols[cdo]=3DFactory[org.eclipse.net4j.clientProtoco ls, cdo], org=
=2Eeclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j. selectors, tc=
p], org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default], org.eclipse.net4j.acceptors[tcp]=3DFactory[o=
rg.eclipse.net4j.acceptors, tcp], org.eclipse.net4j.serverProtocols[cdo]=3D=
Factory[org.eclipse.net4j.serverProtocols, cdo], org.eclipse.net4j.execut=
orServices[default]=3DFactory[org.eclipse.net4j.executorServ ices, default=
]}
main [Lifecycle] DUMP HashMapRegistry@8
Registry.autoCommit =3D true
Registry.transaction =3D null
map =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
main [Lifecycle] DUMP ManagedContainer@9
factoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
postProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
elementRegistry =3D=20
org.eclipse.emf.cdo.server.repositories[default, repo1]=3DRepository[=
repo1, null]
maxElementID =3D 1
elementListener =3D org.eclipse.net4j.internal.util.container.ManagedCon=
tainer$1@25d2b2
main [Lifecycle] Activating BufferPool[4.096]
BufferPoolMonitor [BufferPool] Start monitoring
main [Lifecycle] DUMP BufferPool@10
BufferProvider.bufferCapacity =3D 4096
BufferProvider.providedBuffers =3D 0
BufferProvider.retainedBuffers =3D 0
provider =3D BufferFactory[4.096]
pooledBuffers =3D 0
main [Lifecycle] Activating TCPSelector
main [Lifecycle] DUMP TCPSelector@11
selector =3D sun.nio.ch.WindowsSelectorImpl@1175422
clientOperations =3D=20
serverOperations =3D=20
thread =3D Thread[TCPSelector,5,main]
running =3D true
main [Lifecycle] Activating TCPAcceptor[0.0.0.0:2.036]
main [TCPSelector] Ordering server operation REGISTER sun.nio.ch.ServerSo=
cketChannelImpl[unbound]
TCPSelector [TCPSelector] Executing server operation REGISTER sun.nio.ch.=
ServerSocketChannelImpl[unbound]
TCPSelector [TCPSelector] Registering sun.nio.ch.ServerSocketChannelImpl[=
unbound]
main [Lifecycle] DUMP TCPAcceptor@12
Acceptor.negotiator =3D null
Acceptor.bufferProvider =3D BufferPool[4.096]
Acceptor.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Acceptor.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Acceptor.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8=
e1e
Acceptor.lifecycleEventConverter =3D org.eclipse.internal.net4j.Acceptor=
$1@11671b2
Acceptor.acceptedConnectors =3D=20
selector =3D TCPSelector
selectionKey =3D sun.nio.ch.SelectionKeyImpl@4aa0ce
startSynchronously =3D true
synchronousStartTimeout =3D 4000
startLatch =3D java.util.concurrent.CountDownLatch@12452e8[Count =3D 0]
serverSocketChannel =3D sun.nio.ch.ServerSocketChannelImpl[/0.0.0.0:2036=
]
address =3D 0.0.0.0
port =3D 2036
main [Connector] Setting userID null for {2}
main [Lifecycle] Activating ClientTCPConnector[localhost:2.036]
main [Connector] Setting state CONNECTING (was disconnected) for ClientTC=
PConnector[localhost:2.036]
main [Lifecycle] Activating Channel[Control]
main [Lifecycle] Activating QueueWorkerWorkSerializer@13
main [Lifecycle] DUMP QueueWorkerWorkSerializer@13
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@961dff[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-2,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
main [Lifecycle] DUMP ControlChannel@14
Channel.channelID =3D 0
Channel.channelIndex =3D -1
Channel.connector =3D ClientTCPConnector[localhost:2.036]
Channel.receiveHandler =3D null
Channel.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e=
1e
Channel.receiveSerializer =3D QueueWorkerWorkSerializer@13
Channel.sendQueue =3D=20
registrations =3D SynchronizingCorrelator{}
main [TCPSelector] Ordering client operation REGISTER java.nio.channels.S=
ocketChannel[unconnected]
------------------------ START ------------------------
TCPSelector [TCPSelector] Executing client operation REGISTER java.nio.ch=
annels.SocketChannel[unconnected]
TCPSelector [TCPSelector] Registering java.nio.channels.SocketChannel[unc=
onnected]
TCPSelector [TCPSelector] Connecting java.nio.channels.SocketChannel[conn=
ection-pending remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [TCPSelector] Ordering client operation INTEREST CONNECT java=
=2Enio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3D=
localhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Ordering client operation INTEREST READ java.ni=
o.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocal=
host/127.0.0.1:2036] =3D true
TCPSelector [Connector] Setting state CONNECTED (was connecting) for Clie=
ntTCPConnector[localhost:2.036]
TCPSelector [Lifecycle] DUMP TCPClientConnector@15
Connector.userID =3D null
Connector.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Connector.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Connector.negotiator =3D null
Connector.negotiationContext =3D null
Connector.bufferProvider =3D BufferPool[4.096]
Connector.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc=
8e1e
Connector.nextChannelID =3D 1
Connector.channels =3D=20
Connector.channelsLock =3D org.eclipse.net4j.util.concurrent.RWLock@f8f7=
db[Write locks =3D 0, Read locks =3D 0]
Connector.connectorState =3D CONNECTED
Connector.channelListener =3D org.eclipse.internal.net4j.Connector$1@158=
56a5
Connector.finishedConnecting =3D java.util.concurrent.CountDownLatch@a08=
4f8[Count =3D 1]
Connector.finishedNegotiating =3D java.util.concurrent.CountDownLatch@79=
ed7f[Count =3D 1]
TCPConnector.socketChannel =3D java.nio.channels.SocketChannel[connected=
local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPConnector.selector =3D TCPSelector
TCPConnector.selectionKey =3D sun.nio.ch.SelectionKeyImpl@ac6a45
TCPConnector.inputBuffer =3D null
TCPConnector.controlChannel =3D Channel[Control]
TCPConnector.host =3D localhost
TCPConnector.port =3D 2036
TCPSelector [TCPSelector] Accepting sun.nio.ch.ServerSocketChannelImpl[/0=
=2E0.0.0:2036]
TCPSelector [TCPAcceptor] Accepted socketChannel java.nio.channels.Socket=
Channel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Lifecycle] Activating ServerTCPConnector[127.0.0.1:4.641]
TCPSelector [Connector] Setting state CONNECTING (was disconnected) for S=
erverTCPConnector[127.0.0.1:4.641]
TCPSelector [Lifecycle] Activating Channel[Control]
TCPSelector [Lifecycle] Activating QueueWorkerWorkSerializer@16
TCPSelector [Lifecycle] DUMP QueueWorkerWorkSerializer@16
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@13ad33d[C=
ount =3D 0]
Worker.workerThread =3D Thread[Thread-3,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
TCPSelector [Lifecycle] DUMP ControlChannel@17
Channel.channelID =3D 0
Channel.channelIndex =3D -1
Channel.connector =3D ServerTCPConnector[127.0.0.1:4.641]
Channel.receiveHandler =3D null
Channel.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e=
1e
Channel.receiveSerializer =3D QueueWorkerWorkSerializer@16
Channel.sendQueue =3D=20
registrations =3D SynchronizingCorrelator{}
TCPSelector [TCPSelector] Ordering server operation REGISTER java.nio.cha=
nnels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1=
:4641]
TCPSelector [TCPSelector] Executing server operation REGISTER java.nio.ch=
annels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.0.=
1:4641]
TCPSelector [TCPSelector] Registering java.nio.channels.SocketChannel[con=
nected local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Connector] Setting state CONNECTED (was connecting) for Serv=
erTCPConnector[127.0.0.1:4.641]
TCPSelector [Lifecycle] DUMP TCPServerConnector@18
Connector.userID =3D null
Connector.protocolFactoryRegistry =3D=20
org.eclipse.net4j.connectors[tcp]=3DFactory[org.eclipse.net4 j.connect=
ors, tcp]
org.eclipse.net4j.randomizers[default]=3DFactory[org.eclipse .net4j.ra=
ndomizers, default]
org.eclipse.net4j.clientProtocols[cdo]=3DFactory[org.eclipse .net4j.cl=
ientProtocols, cdo]
org.eclipse.net4j.selectors[tcp]=3DFactory[org.eclipse.net4j .selector=
s, tcp]
org.eclipse.net4j.bufferProviders[default]=3DFactory[org.ecl ipse.net4=
j.bufferProviders, default]
org.eclipse.net4j.acceptors[tcp]=3DFactory[org.eclipse.net4j .acceptor=
s, tcp]
org.eclipse.net4j.serverProtocols[cdo]=3DFactory[org.eclipse .net4j.se=
rverProtocols, cdo]
org.eclipse.net4j.executorServices[default]=3DFactory[org.ec lipse.net=
4j.executorServices, default]
Connector.protocolPostProcessors =3D=20
org.eclipse.internal.net4j.Net4jTransportInjector@110fe28
org.eclipse.net4j.internal.tcp.TCPSelectorInjector@9e29fb
org.eclipse.emf.internal.cdo.LegacyObjectDisabler@1d64c37
Connector.negotiator =3D null
Connector.negotiationContext =3D null
Connector.bufferProvider =3D BufferPool[4.096]
Connector.receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc=
8e1e
Connector.nextChannelID =3D 1
Connector.channels =3D=20
Connector.channelsLock =3D org.eclipse.net4j.util.concurrent.RWLock@1aed=
5f9[Write locks =3D 0, Read locks =3D 0]
Connector.connectorState =3D CONNECTED
Connector.channelListener =3D org.eclipse.internal.net4j.Connector$1@161=
dfb5
Connector.finishedConnecting =3D java.util.concurrent.CountDownLatch@a61=
3f8[Count =3D 1]
Connector.finishedNegotiating =3D java.util.concurrent.CountDownLatch@16=
921fd[Count =3D 1]
TCPConnector.socketChannel =3D java.nio.channels.SocketChannel[connected=
local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPConnector.selector =3D TCPSelector
TCPConnector.selectionKey =3D sun.nio.ch.SelectionKeyImpl@1d6f122
TCPConnector.inputBuffer =3D null
TCPConnector.controlChannel =3D Channel[Control]
TCPConnector.host =3D null
TCPConnector.port =3D 0
acceptor =3D TCPAcceptor[0.0.0.0:2.036]
TCPSelector [Acceptor] Added connector ServerTCPConnector[127.0.0.1:4.641=
]
TCPSelector [TCPSelector] Executing client operation INTEREST CONNECT jav=
a.nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dl=
ocalhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest (was connect)
TCPSelector [TCPSelector] Executing client operation INTEREST READ java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=3Dnull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOObject)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRan=
ge=3Dnull)
main [CDOPackageImpl] Created CDOPackage(URI=3Dhttp://www.eclipse.org/emf=
/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, metaIDRange=3Dn=
ull)
main [CDOClassImpl] Created CDOClass(ID=3D0, name=3DCDOResource)
main [CDOFeatureImpl] Created CDOFeature(ID=3D8, name=3Dpath, type=3DSTRI=
NG, referenceType=3Dnull)
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D8, name=3Dpath, type=3D=
STRING, referenceType=3Dnull)
main [CDOFeatureImpl] Created CDOFeature(ID=3D2, name=3Dcontents, type=3D=
OBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOClassImpl] Adding feature: CDOFeature(ID=3D2, name=3Dcontents, t=
ype=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObject))
main [CDOPackageImpl] Adding class: CDOClass(ID=3D0, name=3DCDOResource)
main [CDOPackageManagerImpl] Added package: CDOPackage(URI=3Dhttp://www.e=
clipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfalse, m=
etaIDRange=3Dnull)
main [CDOModelElementImpl] Setting client info: CDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull) --> org.eclipse.emf.ecore.impl.EcorePackageImpl@6fa9fc (na=
me: ecore) (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore=
)
main [CDOModelElementImpl] Setting client info: CDOClass(ID=3D0, name=3DC=
DOObject) --> org.eclipse.emf.ecore.impl.EClassImpl@3ae941 (name: EObject=
) (instanceClassName: null) (abstract: false, interface: false)
main [CDOModelElementImpl] Setting client info: CDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull) --> org.eclipse.emf.cdo.eresource.impl.EresourcePa=
ckageImpl@4ee70b (name: eresource) (nsURI: http://www.eclipse.org/emf/CDO=
/resource/1.0.0, nsPrefix: eresource)
main [CDOModelElementImpl] Setting client info: CDOClass(ID=3D0, name=3DC=
DOResource) --> org.eclipse.emf.ecore.impl.EClassImpl@55a338 (name: CDORe=
source) (instanceClassName: null) (abstract: false, interface: false)
main [CDOModelElementImpl] Setting client info: CDOFeature(ID=3D2, name=3D=
contents, type=3DOBJECT, referenceType=3DCDOClass(ID=3D0, name=3DCDOObjec=
t)) --> org.eclipse.emf.ecore.impl.EReferenceImpl@22ab57 (name: contents)=
(ordered: true, unique: true, lowerBound: 0, upperBound: -1) (changeable=
: true, volatile: false, transient: false, defaultValueLiteral: null, uns=
ettable: false, derived: false) (containment: true, resolveProxies: false=
)
main [CDOModelElementImpl] Setting client info: CDOFeature(ID=3D8, name=3D=
path, type=3DSTRING, referenceType=3Dnull) --> org.eclipse.emf.ecore.impl=
=2EEAttributeImpl@1eec35 (name: path) (ordered: true, unique: true, lower=
Bound: 0, upperBound: 1) (changeable: true, volatile: false, transient: f=
alse, defaultValueLiteral: null, unsettable: false, derived: false) (iD: =
false)
main [Lifecycle] Activating CDOSession[null/repo1]
main [Connector] Waiting for connection...
main [Lifecycle] Activating SignalProtocol[cdo]
main [Lifecycle] DUMP CDOClientProtocol@19
Protocol.channel =3D Channel[-32.768]
Protocol.infraStructure =3D CDOSession[null/repo1]
SignalProtocol.streamWrapper =3D null
SignalProtocol.signals =3D=20
SignalProtocol.nextCorrelationID =3D 1
main [Connector] Opening channel 0 with protocol cdo
main [ControlChannel] Registering channel 0 with protocol SignalProtocol[=
cdo]
main [BufferFactory] Created Buffer@20
main [BufferPool] Obtained Buffer@20
main [Channel] Handling buffer from client: Buffer@20 --> Channel[Control=
]
main [TCPSelector] Ordering client operation INTEREST WRITE java.nio.chan=
nels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocalhost/1=
27.0.0.1:2036] =3D true
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [Buffer] Writing 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f=20
TCPSelector [BufferPool] Retaining Buffer@20
TCPSelector [TCPSelector] Ordering client operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 12 bytes
02 00 00 00 01 00 00 00 03 63 64 6f=20
TCPSelector [Lifecycle] Activating SignalProtocol[cdo]
TCPSelector [Lifecycle] DUMP CDOServerProtocol@21
Protocol.channel =3D Channel[-32.768]
Protocol.infraStructure =3D org.eclipse.emf.cdo.internal.server.Containe=
rRepositoryProvider@238a47
SignalProtocol.streamWrapper =3D null
SignalProtocol.signals =3D=20
SignalProtocol.nextCorrelationID =3D 1
session =3D null
TCPSelector [Connector] Opening channel 0 with protocol cdo
TCPSelector [Lifecycle] Activating Channel[0]
TCPSelector [Lifecycle] Activating QueueWorkerWorkSerializer@22
TCPSelector [Lifecycle] DUMP QueueWorkerWorkSerializer@22
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@ae533a[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-4,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
TCPSelector [Lifecycle] DUMP Channel@23
channelID =3D 1
channelIndex =3D 0
connector =3D ServerTCPConnector[127.0.0.1:4.641]
receiveHandler =3D SignalProtocol[cdo]
receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e1e
receiveSerializer =3D QueueWorkerWorkSerializer@22
sendQueue =3D=20
TCPSelector [BufferFactory] Created Buffer@24
TCPSelector [BufferPool] Obtained Buffer@24
TCPSelector [Channel] Handling buffer from client: Buffer@24 --> Channel[=
Control]
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D true
TCPSelector [BufferPool] Retaining Buffer@20
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Buffer] Writing 4 bytes
03 00 00 01=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D false
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 4 bytes
03 00 00 01=20
TCPSelector [BufferPool] Retaining Buffer@20
main [Lifecycle] Activating Channel[0]
main [Lifecycle] Activating QueueWorkerWorkSerializer@25
main [Lifecycle] DUMP QueueWorkerWorkSerializer@25
Worker.daemon =3D false
Worker.activationTimeout =3D 2000
Worker.deactivationTimeout =3D 2000
Worker.activationLatch =3D java.util.concurrent.CountDownLatch@401369[Co=
unt =3D 0]
Worker.workerThread =3D Thread[Thread-5,5,main]
QueueWorker.queue =3D=20
QueueWorker.pollMillis =3D 100
main [Lifecycle] DUMP Channel@26
channelID =3D 1
channelIndex =3D 0
connector =3D ClientTCPConnector[localhost:2.036]
receiveHandler =3D SignalProtocol[cdo]
receiveExecutor =3D java.util.concurrent.ThreadPoolExecutor@bc8e1e
receiveSerializer =3D QueueWorkerWorkSerializer@25
sendQueue =3D=20
main [RequestWithConfirmation] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D Requesting OpenSessionRequest
main [OpenSessionRequest] Writing repositoryName: repo1
main [BufferPool] Obtained Buffer@24
main [SignalProtocol] Put signal id 1
main [OpenSessionRequest] Writing disableLegacyObjects: false
main [Channel] Handling buffer from client: Buffer@24 --> Channel[0]
main [TCPSelector] Ordering client operation INTEREST WRITE java.nio.chan=
nels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dlocalhost/1=
27.0.0.1:2036] =3D true
main [RequestWithConfirmation] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D Confirming OpenSessionRequest
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [Buffer] Writing 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering client operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloca=
lhost/127.0.0.1:2036] =3D false
TCPSelector [TCPSelector] Executing client operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:4641 remote=3Dloc=
alhost/127.0.0.1:2036] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 16 bytes (EOS)
00 00 00 01 00 01 01 00 05 72 65 70 6f 31 00 00=20
TCPSelector [Channel] Handling buffer from multiplexer: Buffer@20 --> Cha=
nnel[0]
Thread-4 [SignalProtocol] Received buffer for correlation 1
Thread-4 [SignalProtocol] Got signal id 1
Thread-6 [IndicationWithResponse] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D Indicating OpenSessionIndication
Thread-6 [OpenSessionIndication] Read repositoryName: repo1
Thread-6 [BufferPool] Retaining Buffer@20
Thread-6 [OpenSessionIndication] Read disableLegacyObjects: false
Thread-6 [IndicationWithResponse] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D Responding OpenSessionIndication
Thread-6 [SessionManager] Opening session 1
Thread-6 [Lifecycle] Activating Session[1, Channel[0]]
Thread-6 [Lifecycle] DUMP Session@27
sessionManager =3D SessionManager@4
protocol =3D SignalProtocol[cdo]
sessionID =3D 1
disableLegacyObjects =3D false
views =3D=20
knownTypes =3D=20
protocolListener =3D org.eclipse.emf.cdo.internal.server.Session$1@6e436=
5
Thread-6 [OpenSessionIndication] Writing sessionID: 1
Thread-6 [BufferPool] Obtained Buffer@24
Thread-6 [OpenSessionIndication] Writing repositoryUUID: 0fe540d7-7197-4a=
c8-89c2-6a5b7d654081
Thread-6 [Channel] Handling buffer from client: Buffer@24 --> Channel[0]
Thread-6 [TCPSelector] Ordering server operation INTEREST WRITE java.nio.=
channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127.0.=
0.1:4641] =3D true
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D true
TCPSelector [SelectorUtil] Setting interest READ|WRITE (was read)
TCPSelector [TCPSelector] Writing java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:2036 remote=3D/127.0.0.1:4641]
TCPSelector [Buffer] Writing 49 bytes (EOS)
00 00 00 00 00 00 00 01 01 00 24 30 66 65 35 34 30 64 37 2d 37 31 39 37 2=
d 34 61 63 38 2d 38 39 63 32 2d 36 61 35 62 37 64 36 35 34 30 38 31 00 00=
=20
TCPSelector [BufferPool] Retaining Buffer@24
TCPSelector [TCPSelector] Ordering server operation INTEREST WRITE java.n=
io.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/127=
=2E0.0.1:4641] =3D false
TCPSelector [TCPSelector] Executing server operation INTEREST WRITE java.=
nio.channels.SocketChannel[connected local=3D/127.0.0.1:2036 remote=3D/12=
7.0.0.1:4641] =3D false
TCPSelector [SelectorUtil] Setting interest READ (was read|write)
TCPSelector [TCPSelector] Reading java.nio.channels.SocketChannel[connect=
ed local=3D/127.0.0.1:4641 remote=3Dlocalhost/127.0.0.1:2036]
TCPSelector [BufferPool] Obtained Buffer@20
TCPSelector [Buffer] Read 49 bytes (EOS)
00 00 00 00 00 00 00 01 01 00 24 30 66 65 35 34 30 64 37 2d 37 31 39 37 2=
d 34 61 63 38 2d 38 39 63 32 2d 36 61 35 62 37 64 36 35 34 30 38 31 00 00=
=20
TCPSelector [Channel] Handling buffer from multiplexer: Buffer@20 --> Cha=
nnel[0]
Thread-5 [SignalProtocol] Received buffer for correlation -1
main [OpenSessionRequest] Read sessionID: 1
main [OpenSessionRequest] Read repositoryUUID: 0fe540d7-7197-4ac8-89c2-6a=
5b7d654081
main [BufferPool] Retaining Buffer@20
main [Lifecycle] Activating CDOSessionPackageManager@28
main [Lifecycle] DUMP CDOSessionPackageManager@28
CDOPackageManagerImpl.packages =3D=20
http://www.eclipse.org/emf/CDO/core/1.0.0=3DCDOPackage(URI=3Dhttp://w=
ww.eclipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaI=
DRange=3Dnull)
http://www.eclipse.org/emf/CDO/resource/1.0.0=3DCDOPackage(URI=3Dhttp=
://www.eclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3D=
false, metaIDRange=3Dnull)
CDOPackageManagerImpl.cdoCorePackage =3D CDOPackage(URI=3Dhttp://www.ecl=
ipse.org/emf/CDO/core/1.0.0, name=3Dcdocore, dynamic=3Dfalse, metaIDRange=
=3Dnull)
CDOPackageManagerImpl.cdoResourcePackage =3D CDOPackage(URI=3Dhttp://www=
=2Eeclipse.org/emf/CDO/resource/1.0.0, name=3Dcdoresource, dynamic=3Dfals=
e, metaIDRange=3Dnull)
session =3D CDOSession[ClientTCPConnector[localhost:2.036]/repo1]
main [Lifecycle] Activating CDORevisionManagerImpl@29
main [Lifecycle] DUMP CDORevisionManagerImpl@29
CDORevisionResolverImpl.revisions =3D=20
CDORevisionResolverImpl.currentLRUCapacity =3D 0
CDORevisionResolverImpl.revisedLRUCapacity =3D 0
CDORevisionResolverImpl.currentLRU =3D LRU[size=3D0, capacity=3D0]
CDORevisionResolverImpl.revisedLRU =3D LRU[size=3D0, capacity=3D0]
session =3D CDOSession[ClientTCPConnector[localhost:2.036]/repo1]
ruleManager =3D org.eclipse.emf.internal.cdo.analyzer.NOOPFetchRuleManag=
er@13e754f
main [Lifecycle] DUMP CDOSessionImpl@30
nextTemporaryID =3D -1
sessionID =3D 1
disableLegacyObjects =3D false
referenceChunkSize =3D -1
failOverStrategy =3D null
failOverStrategyListener =3D org.eclipse.emf.internal.cdo.CDOSessionImpl=
$1@15e234c
connector =3D ClientTCPConnector[localhost:2.036]
channel =3D Channel[0]
repositoryName =3D repo1
repositoryUUID =3D 0fe540d7-7197-4ac8-89c2-6a5b7d654081
packageRegistry =3D=20
packageManager =3D CDOSessionPackageManager@28
revisionManager =3D CDORevisionManagerImpl@29
idToMetaInstanceMap =3D=20
metaInstanceToIDMap =3D=20
types =3D=20
views =3D=20
lastViewID =3D 0
channelListener =3D org.eclipse.emf.internal.cdo.CDOSessionImpl$2@15f710=
7
BufferPoolMonitor [BufferPool] Collected buffer
BufferPoolMonitor [BufferPool] Collected buffer
main [CDOSessionImpl] Registering meta instance: -1 <-> org.eclipse.emf.c=
do.tests.model1.impl.Model1PackageImpl@84ce7a (name: model1) (nsURI: http=
://www.eclipse.org/emf/CDO/tests/model1/1.0.0, nsPrefix: model1)
main [CDOSessionImpl] Registering meta instance: -3 <-> org.eclipse.emf.e=
core.impl.EClassImpl@9505f (name: Address) (instanceClassName: null) (abs=
tract: false, interface: false)
main [CDOSessionImpl] Registering meta instance: -5 <-> org.eclipse.emf.e=
core.impl.EAttributeImpl@10fd7f6 (name: name) (ordered: true, unique: tru=
e, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tran=
sient: false, defaultValueLiteral: null, unsettable: false, derived: fals=
e) (iD: false)
main [CDOSessionImpl] Registering meta instance: -7 <-> org.eclipse.emf.e=
core.impl.EGenericTypeImpl@12b6c89 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -9 <-> org.eclipse.emf.e=
core.impl.EAttributeImpl@1e2befa (name: street) (ordered: true, unique: t=
rue, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tr=
ansient: false, defaultValueLiteral: null, unsettable: false, derived: fa=
lse) (iD: false)
main [CDOSessionImpl] Registering meta instance: -11 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@1682598 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -13 <-> org.eclipse.emf.=
ecore.impl.EAttributeImpl@7c3885 (name: city) (ordered: true, unique: tru=
e, lowerBound: 0, upperBound: 1) (changeable: true, volatile: false, tran=
sient: false, defaultValueLiteral: null, unsettable: false, derived: fals=
e) (iD: false)
main [CDOSessionImpl] Registering meta instance: -15 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@162e295 (expression: EString)
main [CDOSessionImpl] Registering meta instance: -17 <-> org.eclipse.emf.=
ecore.impl.EClassImpl@17ba38f (name: Company) (instanceClassName: null) (=
abstract: false, interface: false)
main [CDOSessionImpl] Registering meta instance: -19 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@109de5b (name: categories) (ordered: true, uniq=
ue: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fal=
se, transient: false, defaultValueLiteral: null, unsettable: false, deriv=
ed: false) (containment: true, resolveProxies: false)
main [CDOSessionImpl] Registering meta instance: -21 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@e53220 (expression: Category)
main [CDOSessionImpl] Registering meta instance: -23 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@13e0aba (name: suppliers) (ordered: true, uniqu=
e: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fals=
e, transient: false, defaultValueLiteral: null, unsettable: false, derive=
d: false) (containment: true, resolveProxies: false)
main [CDOSessionImpl] Registering meta instance: -25 <-> org.eclipse.emf.=
ecore.impl.EGenericTypeImpl@3257b8 (expression: Supplier)
main [CDOSessionImpl] Registering meta instance: -27 <-> org.eclipse.emf.=
ecore.impl.EReferenceImpl@11d2572 (name: customers) (ordered: true, uniqu=
e: true, lowerBound: 0, upperBound: -1) (changeable: true, volatile: fals=
e, transient: false, defaultValueLiteral: null, unsettable: false, derive=
d: false) (containment: true, resolveProxies: f
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610461 is a reply to message #101125] |
Thu, 08 November 2007 07:19 |
| Eclipse User |
|
|
|
Mark,
I've just committed a new feature:
1) CDOObject.cdoReload() API
2) "Reload" action in the CDOEditor context menu to reload multiple
selected objects
These can be useful for instance if you rolled back a transaction
locally and wish to revert to the latest remote state.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Eike Stepper schrieb:
> Mark,
>
> There is a Rollback... entry on the transaction's context menu in the
> CDO Sessions view.
> I've just committed two changes:
>
> 1) CDOTransaction API has now a boolean remote parameter on the
> rollback() method.
> Remote rollback will rollback the transaction to reflect the latest
> *remote* state.
> Local rollback will rollback the transaction to reflect the latest
> *local* state. This is not dangerous but can lead to undesired local
> effects when the conflicting object is edited and committed later!
>
> 2) The RollbackTransactionDialog now appears after a version conflict
> is detected on save.
>
> I guess now it'smore obvious what to do ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I have the invalidation notifications working now. But now I need to be
>> able to handle the case where user A modifies an object, but does not
>> save, then user B modified and saves the same object. When user A
>> finally does a save he gets an error that says the version is a
>> duplicate, which makes sense.
>>
>> How do I handle this case in my client with user A losing his work. Can
>> I refresh the objects so that he can save..?
>>
>> Mark.
>>
>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610463 is a reply to message #101933] |
Thu, 08 November 2007 11:04 |
| Eclipse User |
|
|
|
Eike,
I am not at work for about an hour or so to try your test.
However, maybe I was not clear in the desciption of my problem. After I do
the rollback I can go ahead and modify the object and a commit succeeds.
The problem is that the changes are not save in the database. That is, if
I exit both clients and then restart only the first saved changes to the
object are present. The changes made after the rollback and re-commit are
lost.
Am I correct in assuming that your test runs in a single process.? That
seems to be a different environment that I am running, with two instances
on two different machines. Could that effect the results.?
Mark.
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610479 is a reply to message #101971] |
Thu, 08 November 2007 14:33 |
| Eclipse User |
|
|
|
Mark Geib schrieb:
> Eike,
>
> I am not at work for about an hour or so to try your test.
>
> However, maybe I was not clear in the desciption of my problem. After
> I do the rollback I can go ahead and modify the object and a commit
> succeeds. The problem is that the changes are not save in the
> database. That is, if I exit both clients and then restart only the
> first saved changes to the object are present. The changes made after
> the rollback and re-commit are lost.
Ok, I really misinterpreted it first.
But I double checked your "new" scenario and it works perfectly for me.
Have you also tried to verify it with purely CDO provided means? That is
tests.model1 + CDO UI
Another thought: What you describe here could (but doesn't need to)
indicate a problem in the client, although I can't reproduce it here. A
bug in the server would be more likely if the problem occurs after you
restarted the server, but you mention to only restart the clients. I
mean, even if the server would forget to save changes to the database,
it would have the most recent ones in its cache.
> Am I correct in assuming that your test runs in a single process.?
> That seems to be a different environment that I am running, with two
> instances on two different machines. Could that effect the results.?
In general I can't exclude such effect for 100% but I think it's rather
unlikely.
The JUnit tests run in a single process and even without real database
(I use the NOOPStore).
But I've worked many times through all your instructions with a proper 4
process setup: Separate db (Derby+HSQLDB), separate CDO Server + 2
separate UI clients.
Not a single sign that something is wrong.
I fear we have only few options:
1) You get it by looking at your logs (maybe add some traces here and there)
2) You get it with the debugger (which is your friend, i know ;-) )
3) You send me your application via email and I debug it for you
4) You have an idea that I didn't have
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610485 is a reply to message #102044] |
Thu, 08 November 2007 17:31 |
| Eclipse User |
|
|
|
Eike,
I have looking at the logs carefully. After I do the rollback, then
modify the same object that was conflicted, then do a commit I do not
see any traffice for the save/commit. I do not get the event for the
start of the commit or end of the commit.
Do I need to create a new transaction after the rollback, or do
something to prepare the old transaction for use again after the rollback.??
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I am not at work for about an hour or so to try your test.
>>
>> However, maybe I was not clear in the desciption of my problem. After
>> I do the rollback I can go ahead and modify the object and a commit
>> succeeds. The problem is that the changes are not save in the
>> database. That is, if I exit both clients and then restart only the
>> first saved changes to the object are present. The changes made after
>> the rollback and re-commit are lost.
> Ok, I really misinterpreted it first.
> But I double checked your "new" scenario and it works perfectly for me.
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
>
> Another thought: What you describe here could (but doesn't need to)
> indicate a problem in the client, although I can't reproduce it here. A
> bug in the server would be more likely if the problem occurs after you
> restarted the server, but you mention to only restart the clients. I
> mean, even if the server would forget to save changes to the database,
> it would have the most recent ones in its cache.
>
>> Am I correct in assuming that your test runs in a single process.?
>> That seems to be a different environment that I am running, with two
>> instances on two different machines. Could that effect the results.?
> In general I can't exclude such effect for 100% but I think it's rather
> unlikely.
> The JUnit tests run in a single process and even without real database
> (I use the NOOPStore).
> But I've worked many times through all your instructions with a proper 4
> process setup: Separate db (Derby+HSQLDB), separate CDO Server + 2
> separate UI clients.
> Not a single sign that something is wrong.
>
> I fear we have only few options:
> 1) You get it by looking at your logs (maybe add some traces here and
> there)
> 2) You get it with the debugger (which is your friend, i know ;-) )
> 3) You send me your application via email and I debug it for you
> 4) You have an idea that I didn't have
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610487 is a reply to message #102088] |
Thu, 08 November 2007 17:58 |
| Eclipse User |
|
|
|
Mark Geib schrieb:
> Eike,
>
> I have looking at the logs carefully. After I do the rollback, then
> modify the same object that was conflicted, then do a commit I do not
> see any traffice for the save/commit. I do not get the event for the
> start of the commit or end of the commit.
There should be traffic if the transaction is really dirty. If not, it's
a sign that the problem is in the client. There you can use the Net4j
Container view and the Net4j Introspector view to click at runtime
through the user interface elements down to the core elements and browse
their fields. May be this helps you track it down further.
From the log you should be able to locate an appropriate line for a
breakpoint to start debugging at. A high entry could be in the
CommitTransactionAction (if you use that to commit). A low entry could
be CDOTransactionImpl.commit() which is still before the statemachine
for particular objects is triggered.
> Do I need to create a new transaction after the rollback, or do
> something to prepare the old transaction for use again after the
> rollback.??
No, rollback() is sufficient. After that call the transaction should be
non-dirty and all objects with newer remote version should be proxies,
all other objects should be clean.
Have you also tried to verify it with purely CDO provided means? That is
tests.model1 + CDO UI
Just that we have an indication whether the issue occurs there, too.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
..
>
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I am not at work for about an hour or so to try your test.
>>>
>>> However, maybe I was not clear in the desciption of my problem.
>>> After I do the rollback I can go ahead and modify the object and a
>>> commit succeeds. The problem is that the changes are not save in the
>>> database. That is, if I exit both clients and then restart only the
>>> first saved changes to the object are present. The changes made
>>> after the rollback and re-commit are lost.
>> Ok, I really misinterpreted it first.
>> But I double checked your "new" scenario and it works perfectly for me.
>> Have you also tried to verify it with purely CDO provided means? That
>> is tests.model1 + CDO UI
>>
>> Another thought: What you describe here could (but doesn't need to)
>> indicate a problem in the client, although I can't reproduce it here.
>> A bug in the server would be more likely if the problem occurs after
>> you restarted the server, but you mention to only restart the
>> clients. I mean, even if the server would forget to save changes to
>> the database, it would have the most recent ones in its cache.
>>
>>> Am I correct in assuming that your test runs in a single process.?
>>> That seems to be a different environment that I am running, with two
>>> instances on two different machines. Could that effect the results.?
>> In general I can't exclude such effect for 100% but I think it's
>> rather unlikely.
>> The JUnit tests run in a single process and even without real
>> database (I use the NOOPStore).
>> But I've worked many times through all your instructions with a
>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>> Server + 2 separate UI clients.
>> Not a single sign that something is wrong.
>>
>> I fear we have only few options:
>> 1) You get it by looking at your logs (maybe add some traces here and
>> there)
>> 2) You get it with the debugger (which is your friend, i know ;-) )
>> 3) You send me your application via email and I debug it for you
>> 4) You have an idea that I didn't have
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610488 is a reply to message #102115] |
Thu, 08 November 2007 18:49 |
| Eclipse User |
|
|
|
Eike,
I quickly debugged my save method and inspected the transaction. It is
not dirty, that must be the issue.
Why is not dirty, I have changed an attribute.
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I have looking at the logs carefully. After I do the rollback, then
>> modify the same object that was conflicted, then do a commit I do not
>> see any traffice for the save/commit. I do not get the event for the
>> start of the commit or end of the commit.
> There should be traffic if the transaction is really dirty. If not, it's
> a sign that the problem is in the client. There you can use the Net4j
> Container view and the Net4j Introspector view to click at runtime
> through the user interface elements down to the core elements and browse
> their fields. May be this helps you track it down further.
>
> From the log you should be able to locate an appropriate line for a
> breakpoint to start debugging at. A high entry could be in the
> CommitTransactionAction (if you use that to commit). A low entry could
> be CDOTransactionImpl.commit() which is still before the statemachine
> for particular objects is triggered.
>
>> Do I need to create a new transaction after the rollback, or do
>> something to prepare the old transaction for use again after the
>> rollback.??
> No, rollback() is sufficient. After that call the transaction should be
> non-dirty and all objects with newer remote version should be proxies,
> all other objects should be clean.
>
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
> Just that we have an indication whether the issue occurs there, too.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> .
>
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I am not at work for about an hour or so to try your test.
>>>>
>>>> However, maybe I was not clear in the desciption of my problem.
>>>> After I do the rollback I can go ahead and modify the object and a
>>>> commit succeeds. The problem is that the changes are not save in the
>>>> database. That is, if I exit both clients and then restart only the
>>>> first saved changes to the object are present. The changes made
>>>> after the rollback and re-commit are lost.
>>> Ok, I really misinterpreted it first.
>>> But I double checked your "new" scenario and it works perfectly for me.
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>>
>>> Another thought: What you describe here could (but doesn't need to)
>>> indicate a problem in the client, although I can't reproduce it here.
>>> A bug in the server would be more likely if the problem occurs after
>>> you restarted the server, but you mention to only restart the
>>> clients. I mean, even if the server would forget to save changes to
>>> the database, it would have the most recent ones in its cache.
>>>
>>>> Am I correct in assuming that your test runs in a single process.?
>>>> That seems to be a different environment that I am running, with two
>>>> instances on two different machines. Could that effect the results.?
>>> In general I can't exclude such effect for 100% but I think it's
>>> rather unlikely.
>>> The JUnit tests run in a single process and even without real
>>> database (I use the NOOPStore).
>>> But I've worked many times through all your instructions with a
>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>> Server + 2 separate UI clients.
>>> Not a single sign that something is wrong.
>>>
>>> I fear we have only few options:
>>> 1) You get it by looking at your logs (maybe add some traces here and
>>> there)
>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>> 3) You send me your application via email and I debug it for you
>>> 4) You have an idea that I didn't have
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610489 is a reply to message #102115] |
Thu, 08 November 2007 19:02 |
| Eclipse User |
|
|
|
Eike,
I also see in the logs that the state of the object is CONFLICT rather
than DIRTY prior to the commit which does nothing.
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I have looking at the logs carefully. After I do the rollback, then
>> modify the same object that was conflicted, then do a commit I do not
>> see any traffice for the save/commit. I do not get the event for the
>> start of the commit or end of the commit.
> There should be traffic if the transaction is really dirty. If not, it's
> a sign that the problem is in the client. There you can use the Net4j
> Container view and the Net4j Introspector view to click at runtime
> through the user interface elements down to the core elements and browse
> their fields. May be this helps you track it down further.
>
> From the log you should be able to locate an appropriate line for a
> breakpoint to start debugging at. A high entry could be in the
> CommitTransactionAction (if you use that to commit). A low entry could
> be CDOTransactionImpl.commit() which is still before the statemachine
> for particular objects is triggered.
>
>> Do I need to create a new transaction after the rollback, or do
>> something to prepare the old transaction for use again after the
>> rollback.??
> No, rollback() is sufficient. After that call the transaction should be
> non-dirty and all objects with newer remote version should be proxies,
> all other objects should be clean.
>
> Have you also tried to verify it with purely CDO provided means? That is
> tests.model1 + CDO UI
> Just that we have an indication whether the issue occurs there, too.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
> .
>
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I am not at work for about an hour or so to try your test.
>>>>
>>>> However, maybe I was not clear in the desciption of my problem.
>>>> After I do the rollback I can go ahead and modify the object and a
>>>> commit succeeds. The problem is that the changes are not save in the
>>>> database. That is, if I exit both clients and then restart only the
>>>> first saved changes to the object are present. The changes made
>>>> after the rollback and re-commit are lost.
>>> Ok, I really misinterpreted it first.
>>> But I double checked your "new" scenario and it works perfectly for me.
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>>
>>> Another thought: What you describe here could (but doesn't need to)
>>> indicate a problem in the client, although I can't reproduce it here.
>>> A bug in the server would be more likely if the problem occurs after
>>> you restarted the server, but you mention to only restart the
>>> clients. I mean, even if the server would forget to save changes to
>>> the database, it would have the most recent ones in its cache.
>>>
>>>> Am I correct in assuming that your test runs in a single process.?
>>>> That seems to be a different environment that I am running, with two
>>>> instances on two different machines. Could that effect the results.?
>>> In general I can't exclude such effect for 100% but I think it's
>>> rather unlikely.
>>> The JUnit tests run in a single process and even without real
>>> database (I use the NOOPStore).
>>> But I've worked many times through all your instructions with a
>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>> Server + 2 separate UI clients.
>>> Not a single sign that something is wrong.
>>>
>>> I fear we have only few options:
>>> 1) You get it by looking at your logs (maybe add some traces here and
>>> there)
>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>> 3) You send me your application via email and I debug it for you
>>> 4) You have an idea that I didn't have
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #610490 is a reply to message #102143] |
Fri, 09 November 2007 01:44 |
| Eclipse User |
|
|
|
Mark,
I think this is the root cause. The transaction not being dirty is most
probably a followup problem because object state CONFLICT can't be left
via event WRITE, see CDOStateMachine:
init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
Please use the Introspector view to verify the state of the conflicting
objects and the transaction itself before and after the rollback(). The
CDOTransactionImpl.cleanUp() method should bring the transaction in a
proper state after commit() and rollback():
public void rollback(boolean remote)
{
try
{
if (!newResources.isEmpty())
{
for (CDOObject newResource : newResources.values())
{
removeObject(newResource.cdoID());
getResourceSet().getResources().remove(newResource);
}
}
if (!newObjects.isEmpty())
{
for (CDOObject newObject : newObjects.values())
{
removeObject(newObject.cdoID());
}
}
if (!dirtyObjects.isEmpty())
{
for (CDOObject dirtyObject : dirtyObjects.values())
{
CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
}
}
cleanUp();
Map<CDOID, CDOID> idMappings = Collections.emptyMap();
fireEvent(new
FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
}
catch (RuntimeException ex)
{
throw ex;
}
catch (Exception ex)
{
throw new TransactionException(ex);
}
}
private void cleanUp()
{
newPackages = null;
newResources.clear();
newObjects.clear();
dirtyObjects.clear();
dirty = false;
conflict = false;
nextTemporaryID = INITIAL_TEMPORARY_ID;
}
BTW. I checked again that all the states have proper values all over the
process here.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> I also see in the logs that the state of the object is CONFLICT rather
> than DIRTY prior to the commit which does nothing.
>
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I have looking at the logs carefully. After I do the rollback, then
>>> modify the same object that was conflicted, then do a commit I do
>>> not see any traffice for the save/commit. I do not get the event for
>>> the start of the commit or end of the commit.
>> There should be traffic if the transaction is really dirty. If not,
>> it's a sign that the problem is in the client. There you can use the
>> Net4j Container view and the Net4j Introspector view to click at
>> runtime through the user interface elements down to the core elements
>> and browse their fields. May be this helps you track it down further.
>>
>> From the log you should be able to locate an appropriate line for a
>> breakpoint to start debugging at. A high entry could be in the
>> CommitTransactionAction (if you use that to commit). A low entry
>> could be CDOTransactionImpl.commit() which is still before the
>> statemachine for particular objects is triggered.
>>
>>> Do I need to create a new transaction after the rollback, or do
>>> something to prepare the old transaction for use again after the
>>> rollback.??
>> No, rollback() is sufficient. After that call the transaction should
>> be non-dirty and all objects with newer remote version should be
>> proxies, all other objects should be clean.
>>
>> Have you also tried to verify it with purely CDO provided means? That
>> is tests.model1 + CDO UI
>> Just that we have an indication whether the issue occurs there, too.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>> .
>>
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I am not at work for about an hour or so to try your test.
>>>>>
>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>> commit succeeds. The problem is that the changes are not save in
>>>>> the database. That is, if I exit both clients and then restart
>>>>> only the first saved changes to the object are present. The
>>>>> changes made after the rollback and re-commit are lost.
>>>> Ok, I really misinterpreted it first.
>>>> But I double checked your "new" scenario and it works perfectly for
>>>> me.
>>>> Have you also tried to verify it with purely CDO provided means?
>>>> That is tests.model1 + CDO UI
>>>>
>>>> Another thought: What you describe here could (but doesn't need
>>>> to) indicate a problem in the client, although I can't reproduce
>>>> it here. A bug in the server would be more likely if the problem
>>>> occurs after you restarted the server, but you mention to only
>>>> restart the clients. I mean, even if the server would forget to
>>>> save changes to the database, it would have the most recent ones in
>>>> its cache.
>>>>
>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>> That seems to be a different environment that I am running, with
>>>>> two instances on two different machines. Could that effect the
>>>>> results.?
>>>> In general I can't exclude such effect for 100% but I think it's
>>>> rather unlikely.
>>>> The JUnit tests run in a single process and even without real
>>>> database (I use the NOOPStore).
>>>> But I've worked many times through all your instructions with a
>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>> Server + 2 separate UI clients.
>>>> Not a single sign that something is wrong.
>>>>
>>>> I fear we have only few options:
>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>> and there)
>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>> 3) You send me your application via email and I debug it for you
>>>> 4) You have an idea that I didn't have
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612432 is a reply to message #102157] |
Fri, 09 November 2007 11:26 |
| Eclipse User |
|
|
|
Eike,
I stepped through my event handler and watched the log. During the time
my code is handling the conflict I see everything look normal. When the
listener exits the state is CLEAN, then I continue stepping and the
method ConflictTransition.execute() then sets the state to CONFLICT.
It looks like what ever I do to effect the state of the object is
overwritten by this code setting state back to CONFLICT.
Mark.
Eike Stepper wrote:
> Mark,
>
> I think this is the root cause. The transaction not being dirty is most
> probably a followup problem because object state CONFLICT can't be left
> via event WRITE, see CDOStateMachine:
>
> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>
> Please use the Introspector view to verify the state of the conflicting
> objects and the transaction itself before and after the rollback(). The
> CDOTransactionImpl.cleanUp() method should bring the transaction in a
> proper state after commit() and rollback():
>
> public void rollback(boolean remote)
> {
> try
> {
> if (!newResources.isEmpty())
> {
> for (CDOObject newResource : newResources.values())
> {
> removeObject(newResource.cdoID());
> getResourceSet().getResources().remove(newResource);
> }
> }
>
> if (!newObjects.isEmpty())
> {
> for (CDOObject newObject : newObjects.values())
> {
> removeObject(newObject.cdoID());
> }
> }
>
> if (!dirtyObjects.isEmpty())
> {
> for (CDOObject dirtyObject : dirtyObjects.values())
> {
>
> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
> }
> }
>
> cleanUp();
> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
> fireEvent(new
> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
> }
> catch (RuntimeException ex)
> {
> throw ex;
> }
> catch (Exception ex)
> {
> throw new TransactionException(ex);
> }
> }
>
> private void cleanUp()
> {
> newPackages = null;
> newResources.clear();
> newObjects.clear();
> dirtyObjects.clear();
> dirty = false;
> conflict = false;
> nextTemporaryID = INITIAL_TEMPORARY_ID;
> }
>
> BTW. I checked again that all the states have proper values all over the
> process here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I also see in the logs that the state of the object is CONFLICT rather
>> than DIRTY prior to the commit which does nothing.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I have looking at the logs carefully. After I do the rollback, then
>>>> modify the same object that was conflicted, then do a commit I do
>>>> not see any traffice for the save/commit. I do not get the event for
>>>> the start of the commit or end of the commit.
>>> There should be traffic if the transaction is really dirty. If not,
>>> it's a sign that the problem is in the client. There you can use the
>>> Net4j Container view and the Net4j Introspector view to click at
>>> runtime through the user interface elements down to the core elements
>>> and browse their fields. May be this helps you track it down further.
>>>
>>> From the log you should be able to locate an appropriate line for a
>>> breakpoint to start debugging at. A high entry could be in the
>>> CommitTransactionAction (if you use that to commit). A low entry
>>> could be CDOTransactionImpl.commit() which is still before the
>>> statemachine for particular objects is triggered.
>>>
>>>> Do I need to create a new transaction after the rollback, or do
>>>> something to prepare the old transaction for use again after the
>>>> rollback.??
>>> No, rollback() is sufficient. After that call the transaction should
>>> be non-dirty and all objects with newer remote version should be
>>> proxies, all other objects should be clean.
>>>
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>> Just that we have an indication whether the issue occurs there, too.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>> .
>>>
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>
>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>>> commit succeeds. The problem is that the changes are not save in
>>>>>> the database. That is, if I exit both clients and then restart
>>>>>> only the first saved changes to the object are present. The
>>>>>> changes made after the rollback and re-commit are lost.
>>>>> Ok, I really misinterpreted it first.
>>>>> But I double checked your "new" scenario and it works perfectly for
>>>>> me.
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>>
>>>>> Another thought: What you describe here could (but doesn't need
>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>> it here. A bug in the server would be more likely if the problem
>>>>> occurs after you restarted the server, but you mention to only
>>>>> restart the clients. I mean, even if the server would forget to
>>>>> save changes to the database, it would have the most recent ones in
>>>>> its cache.
>>>>>
>>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>>> That seems to be a different environment that I am running, with
>>>>>> two instances on two different machines. Could that effect the
>>>>>> results.?
>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>> rather unlikely.
>>>>> The JUnit tests run in a single process and even without real
>>>>> database (I use the NOOPStore).
>>>>> But I've worked many times through all your instructions with a
>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>> Server + 2 separate UI clients.
>>>>> Not a single sign that something is wrong.
>>>>>
>>>>> I fear we have only few options:
>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>> and there)
>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>> 3) You send me your application via email and I debug it for you
>>>>> 4) You have an idea that I didn't have
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612435 is a reply to message #102157] |
Fri, 09 November 2007 12:00 |
| Eclipse User |
|
|
|
Eike,
OK, I changed my approach with some success.
Instead of adding the listener and handling the conflict when the second
client saves I now check the transaction in my save method. If the
transaction is dirty and conflicted then I just rollback and commit. Now
everything is useable, that is, I can then re-modify the objects and do
a successful commit from client 1.
Mark.
Eike Stepper wrote:
> Mark,
>
> I think this is the root cause. The transaction not being dirty is most
> probably a followup problem because object state CONFLICT can't be left
> via event WRITE, see CDOStateMachine:
>
> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>
> Please use the Introspector view to verify the state of the conflicting
> objects and the transaction itself before and after the rollback(). The
> CDOTransactionImpl.cleanUp() method should bring the transaction in a
> proper state after commit() and rollback():
>
> public void rollback(boolean remote)
> {
> try
> {
> if (!newResources.isEmpty())
> {
> for (CDOObject newResource : newResources.values())
> {
> removeObject(newResource.cdoID());
> getResourceSet().getResources().remove(newResource);
> }
> }
>
> if (!newObjects.isEmpty())
> {
> for (CDOObject newObject : newObjects.values())
> {
> removeObject(newObject.cdoID());
> }
> }
>
> if (!dirtyObjects.isEmpty())
> {
> for (CDOObject dirtyObject : dirtyObjects.values())
> {
>
> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject, remote);
> }
> }
>
> cleanUp();
> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
> fireEvent(new
> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK, idMappings));
> }
> catch (RuntimeException ex)
> {
> throw ex;
> }
> catch (Exception ex)
> {
> throw new TransactionException(ex);
> }
> }
>
> private void cleanUp()
> {
> newPackages = null;
> newResources.clear();
> newObjects.clear();
> dirtyObjects.clear();
> dirty = false;
> conflict = false;
> nextTemporaryID = INITIAL_TEMPORARY_ID;
> }
>
> BTW. I checked again that all the states have proper values all over the
> process here.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I also see in the logs that the state of the object is CONFLICT rather
>> than DIRTY prior to the commit which does nothing.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I have looking at the logs carefully. After I do the rollback, then
>>>> modify the same object that was conflicted, then do a commit I do
>>>> not see any traffice for the save/commit. I do not get the event for
>>>> the start of the commit or end of the commit.
>>> There should be traffic if the transaction is really dirty. If not,
>>> it's a sign that the problem is in the client. There you can use the
>>> Net4j Container view and the Net4j Introspector view to click at
>>> runtime through the user interface elements down to the core elements
>>> and browse their fields. May be this helps you track it down further.
>>>
>>> From the log you should be able to locate an appropriate line for a
>>> breakpoint to start debugging at. A high entry could be in the
>>> CommitTransactionAction (if you use that to commit). A low entry
>>> could be CDOTransactionImpl.commit() which is still before the
>>> statemachine for particular objects is triggered.
>>>
>>>> Do I need to create a new transaction after the rollback, or do
>>>> something to prepare the old transaction for use again after the
>>>> rollback.??
>>> No, rollback() is sufficient. After that call the transaction should
>>> be non-dirty and all objects with newer remote version should be
>>> proxies, all other objects should be clean.
>>>
>>> Have you also tried to verify it with purely CDO provided means? That
>>> is tests.model1 + CDO UI
>>> Just that we have an indication whether the issue occurs there, too.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>> .
>>>
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>
>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>> After I do the rollback I can go ahead and modify the object and a
>>>>>> commit succeeds. The problem is that the changes are not save in
>>>>>> the database. That is, if I exit both clients and then restart
>>>>>> only the first saved changes to the object are present. The
>>>>>> changes made after the rollback and re-commit are lost.
>>>>> Ok, I really misinterpreted it first.
>>>>> But I double checked your "new" scenario and it works perfectly for
>>>>> me.
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>>
>>>>> Another thought: What you describe here could (but doesn't need
>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>> it here. A bug in the server would be more likely if the problem
>>>>> occurs after you restarted the server, but you mention to only
>>>>> restart the clients. I mean, even if the server would forget to
>>>>> save changes to the database, it would have the most recent ones in
>>>>> its cache.
>>>>>
>>>>>> Am I correct in assuming that your test runs in a single process.?
>>>>>> That seems to be a different environment that I am running, with
>>>>>> two instances on two different machines. Could that effect the
>>>>>> results.?
>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>> rather unlikely.
>>>>> The JUnit tests run in a single process and even without real
>>>>> database (I use the NOOPStore).
>>>>> But I've worked many times through all your instructions with a
>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>> Server + 2 separate UI clients.
>>>>> Not a single sign that something is wrong.
>>>>>
>>>>> I fear we have only few options:
>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>> and there)
>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>> 3) You send me your application via email and I debug it for you
>>>>> 4) You have an idea that I didn't have
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612439 is a reply to message #102270] |
Fri, 09 November 2007 13:13 |
| Eclipse User |
|
|
|
Mark,
From your writing I get the impression that the cause was in your
client code.
I must admit that I don't have a clear picture of what was wrong and to
what you changed it.
If you say it was a silly fault, it's ok for me ;-)
If you feel that the CDO API is not clear enough or the wiki could have
a FAQ entry to prevent others from running into an open trap, then I'd
appreciate if you make it clear with code examples, so that I can
publish it.
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> OK, I changed my approach with some success.
>
> Instead of adding the listener and handling the conflict when the
> second client saves I now check the transaction in my save method. If
> the transaction is dirty and conflicted then I just rollback and
> commit. Now everything is useable, that is, I can then re-modify the
> objects and do a successful commit from client 1.
>
> Mark.
>
> Eike Stepper wrote:
>> Mark,
>>
>> I think this is the root cause. The transaction not being dirty is
>> most probably a followup problem because object state CONFLICT can't
>> be left via event WRITE, see CDOStateMachine:
>>
>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>
>> Please use the Introspector view to verify the state of the
>> conflicting objects and the transaction itself before and after the
>> rollback(). The CDOTransactionImpl.cleanUp() method should bring the
>> transaction in a proper state after commit() and rollback():
>>
>> public void rollback(boolean remote)
>> {
>> try
>> {
>> if (!newResources.isEmpty())
>> {
>> for (CDOObject newResource : newResources.values())
>> {
>> removeObject(newResource.cdoID());
>> getResourceSet().getResources().remove(newResource);
>> }
>> }
>>
>> if (!newObjects.isEmpty())
>> {
>> for (CDOObject newObject : newObjects.values())
>> {
>> removeObject(newObject.cdoID());
>> }
>> }
>>
>> if (!dirtyObjects.isEmpty())
>> {
>> for (CDOObject dirtyObject : dirtyObjects.values())
>> {
>>
>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>> remote);
>> }
>> }
>>
>> cleanUp();
>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>> fireEvent(new
>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>> idMappings));
>> }
>> catch (RuntimeException ex)
>> {
>> throw ex;
>> }
>> catch (Exception ex)
>> {
>> throw new TransactionException(ex);
>> }
>> }
>>
>> private void cleanUp()
>> {
>> newPackages = null;
>> newResources.clear();
>> newObjects.clear();
>> dirtyObjects.clear();
>> dirty = false;
>> conflict = false;
>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>> }
>>
>> BTW. I checked again that all the states have proper values all over
>> the process here.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>
>>
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I also see in the logs that the state of the object is CONFLICT
>>> rather than DIRTY prior to the commit which does nothing.
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>> then modify the same object that was conflicted, then do a commit
>>>>> I do not see any traffice for the save/commit. I do not get the
>>>>> event for the start of the commit or end of the commit.
>>>> There should be traffic if the transaction is really dirty. If not,
>>>> it's a sign that the problem is in the client. There you can use
>>>> the Net4j Container view and the Net4j Introspector view to click
>>>> at runtime through the user interface elements down to the core
>>>> elements and browse their fields. May be this helps you track it
>>>> down further.
>>>>
>>>> From the log you should be able to locate an appropriate line for
>>>> a breakpoint to start debugging at. A high entry could be in the
>>>> CommitTransactionAction (if you use that to commit). A low entry
>>>> could be CDOTransactionImpl.commit() which is still before the
>>>> statemachine for particular objects is triggered.
>>>>
>>>>> Do I need to create a new transaction after the rollback, or do
>>>>> something to prepare the old transaction for use again after the
>>>>> rollback.??
>>>> No, rollback() is sufficient. After that call the transaction
>>>> should be non-dirty and all objects with newer remote version
>>>> should be proxies, all other objects should be clean.
>>>>
>>>> Have you also tried to verify it with purely CDO provided means?
>>>> That is tests.model1 + CDO UI
>>>> Just that we have an indication whether the issue occurs there, too.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>> .
>>>>
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>
>>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>>> After I do the rollback I can go ahead and modify the object and
>>>>>>> a commit succeeds. The problem is that the changes are not save
>>>>>>> in the database. That is, if I exit both clients and then
>>>>>>> restart only the first saved changes to the object are present.
>>>>>>> The changes made after the rollback and re-commit are lost.
>>>>>> Ok, I really misinterpreted it first.
>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>> for me.
>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>> That is tests.model1 + CDO UI
>>>>>>
>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>>> it here. A bug in the server would be more likely if the problem
>>>>>> occurs after you restarted the server, but you mention to only
>>>>>> restart the clients. I mean, even if the server would forget to
>>>>>> save changes to the database, it would have the most recent ones
>>>>>> in its cache.
>>>>>>
>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>> process.? That seems to be a different environment that I am
>>>>>>> running, with two instances on two different machines. Could
>>>>>>> that effect the results.?
>>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>>> rather unlikely.
>>>>>> The JUnit tests run in a single process and even without real
>>>>>> database (I use the NOOPStore).
>>>>>> But I've worked many times through all your instructions with a
>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>>> Server + 2 separate UI clients.
>>>>>> Not a single sign that something is wrong.
>>>>>>
>>>>>> I fear we have only few options:
>>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>>> and there)
>>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>>> 3) You send me your application via email and I debug it for you
>>>>>> 4) You have an idea that I didn't have
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612442 is a reply to message #102288] |
Fri, 09 November 2007 13:16 |
| Eclipse User |
|
|
|
Eike,
I guess I was a bit confused that I could not do anything in the event
handler that effected the object state. It would seem that I should be
able to take some action there to handle the event, like doing a
rollback, etc. I understand that the state machine must control the state.
I do have a couple questions.
o Can I tell what objects are deleted in the transaction.?? I can get
the dirty and new, be not the deleted.
o Does it make sense to undo my command stack when ever I call rollback
on a transaction, to keep my GUI consistent with my model objects.?? I
am still working on this...
o Do you any kind of roadmap for CDO. I am planning to release my system
using CDO very soon and need some help on when to freeze the CDO/Net4J
versions. I had planned to use a real release of CDO when I do my
release so that I do not build and release something slightly different
than that provided on the eclipse site for CDO.
Mark.
Eike Stepper wrote:
> Mark,
>
> From your writing I get the impression that the cause was in your
> client code.
> I must admit that I don't have a clear picture of what was wrong and to
> what you changed it.
> If you say it was a silly fault, it's ok for me ;-)
> If you feel that the CDO API is not clear enough or the wiki could have
> a FAQ entry to prevent others from running into an open trap, then I'd
> appreciate if you make it clear with code examples, so that I can
> publish it.
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> OK, I changed my approach with some success.
>>
>> Instead of adding the listener and handling the conflict when the
>> second client saves I now check the transaction in my save method. If
>> the transaction is dirty and conflicted then I just rollback and
>> commit. Now everything is useable, that is, I can then re-modify the
>> objects and do a successful commit from client 1.
>>
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark,
>>>
>>> I think this is the root cause. The transaction not being dirty is
>>> most probably a followup problem because object state CONFLICT can't
>>> be left via event WRITE, see CDOStateMachine:
>>>
>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new RollbackTransition());
>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>
>>> Please use the Introspector view to verify the state of the
>>> conflicting objects and the transaction itself before and after the
>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring the
>>> transaction in a proper state after commit() and rollback():
>>>
>>> public void rollback(boolean remote)
>>> {
>>> try
>>> {
>>> if (!newResources.isEmpty())
>>> {
>>> for (CDOObject newResource : newResources.values())
>>> {
>>> removeObject(newResource.cdoID());
>>> getResourceSet().getResources().remove(newResource);
>>> }
>>> }
>>>
>>> if (!newObjects.isEmpty())
>>> {
>>> for (CDOObject newObject : newObjects.values())
>>> {
>>> removeObject(newObject.cdoID());
>>> }
>>> }
>>>
>>> if (!dirtyObjects.isEmpty())
>>> {
>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>> {
>>>
>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>> remote);
>>> }
>>> }
>>>
>>> cleanUp();
>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>> fireEvent(new
>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>> idMappings));
>>> }
>>> catch (RuntimeException ex)
>>> {
>>> throw ex;
>>> }
>>> catch (Exception ex)
>>> {
>>> throw new TransactionException(ex);
>>> }
>>> }
>>>
>>> private void cleanUp()
>>> {
>>> newPackages = null;
>>> newResources.clear();
>>> newObjects.clear();
>>> dirtyObjects.clear();
>>> dirty = false;
>>> conflict = false;
>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>> }
>>>
>>> BTW. I checked again that all the states have proper values all over
>>> the process here.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>>
>>>
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I also see in the logs that the state of the object is CONFLICT
>>>> rather than DIRTY prior to the commit which does nothing.
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>> then modify the same object that was conflicted, then do a commit
>>>>>> I do not see any traffice for the save/commit. I do not get the
>>>>>> event for the start of the commit or end of the commit.
>>>>> There should be traffic if the transaction is really dirty. If not,
>>>>> it's a sign that the problem is in the client. There you can use
>>>>> the Net4j Container view and the Net4j Introspector view to click
>>>>> at runtime through the user interface elements down to the core
>>>>> elements and browse their fields. May be this helps you track it
>>>>> down further.
>>>>>
>>>>> From the log you should be able to locate an appropriate line for
>>>>> a breakpoint to start debugging at. A high entry could be in the
>>>>> CommitTransactionAction (if you use that to commit). A low entry
>>>>> could be CDOTransactionImpl.commit() which is still before the
>>>>> statemachine for particular objects is triggered.
>>>>>
>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>> something to prepare the old transaction for use again after the
>>>>>> rollback.??
>>>>> No, rollback() is sufficient. After that call the transaction
>>>>> should be non-dirty and all objects with newer remote version
>>>>> should be proxies, all other objects should be clean.
>>>>>
>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>> That is tests.model1 + CDO UI
>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>> .
>>>>>
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>
>>>>>>>> However, maybe I was not clear in the desciption of my problem.
>>>>>>>> After I do the rollback I can go ahead and modify the object and
>>>>>>>> a commit succeeds. The problem is that the changes are not save
>>>>>>>> in the database. That is, if I exit both clients and then
>>>>>>>> restart only the first saved changes to the object are present.
>>>>>>>> The changes made after the rollback and re-commit are lost.
>>>>>>> Ok, I really misinterpreted it first.
>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>> for me.
>>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>>> That is tests.model1 + CDO UI
>>>>>>>
>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>> to) indicate a problem in the client, although I can't reproduce
>>>>>>> it here. A bug in the server would be more likely if the problem
>>>>>>> occurs after you restarted the server, but you mention to only
>>>>>>> restart the clients. I mean, even if the server would forget to
>>>>>>> save changes to the database, it would have the most recent ones
>>>>>>> in its cache.
>>>>>>>
>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>> that effect the results.?
>>>>>>> In general I can't exclude such effect for 100% but I think it's
>>>>>>> rather unlikely.
>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>> database (I use the NOOPStore).
>>>>>>> But I've worked many times through all your instructions with a
>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate CDO
>>>>>>> Server + 2 separate UI clients.
>>>>>>> Not a single sign that something is wrong.
>>>>>>>
>>>>>>> I fear we have only few options:
>>>>>>> 1) You get it by looking at your logs (maybe add some traces here
>>>>>>> and there)
>>>>>>> 2) You get it with the debugger (which is your friend, i know ;-) )
>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>> 4) You have an idea that I didn't have
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612445 is a reply to message #102295] |
Fri, 09 November 2007 14:31 |
| Eclipse User |
|
|
|
Mark Geib schrieb:
> Eike,
>
> I guess I was a bit confused that I could not do anything in the event
> handler that effected the object state. It would seem that I should be
> able to take some action there to handle the event, like doing a
> rollback, etc. I understand that the state machine must control the
> state.
>
> I do have a couple questions.
>
> o Can I tell what objects are deleted in the transaction.?? I can get
> the dirty and new, be not the deleted.
The deleted objects are those with
cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
If you think I should provide a convenience getter in CDOTransaction
please open a feature request for CDO 0.8.
> o Does it make sense to undo my command stack when ever I call
> rollback on a transaction, to keep my GUI consistent with my model
> objects.?? I am still working on this...
No, I don't think so. Undo works but from a CDO framework perspective it
is like the client application, it modifies the objects via normal
EObject API and not via the CDOStore. As a result CDO can't distinguish
between CommandStack access and normal client code access. The
transaction will become dirty. I couldn't find a situation where this is
dangerous for the data but it depends on what you want to achieve.
> o Do you any kind of roadmap for CDO. I am planning to release my
> system using CDO very soon and need some help on when to freeze the
> CDO/Net4J versions. I had planned to use a real release of CDO when I
> do my release so that I do not build and release something slightly
> different than that provided on the eclipse site for CDO.
Hmm, I don't have a written road map and CDO is currrently in a state
where no very obvious things are missing. But I have some ideas and some
are already documented:
https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
Note that a dozen of them or so are already implemented (due to a
problem with the releng infra structure I can't move them to RESOLVED,
Nick is working on that).
Why are asking, do you want to consider some new features or are you
afraid of coming API changes?
Regards,
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
>
> Mark.
>
>
>
> Eike Stepper wrote:
>> Mark,
>>
>> From your writing I get the impression that the cause was in your
>> client code.
>> I must admit that I don't have a clear picture of what was wrong and
>> to what you changed it.
>> If you say it was a silly fault, it's ok for me ;-)
>> If you feel that the CDO API is not clear enough or the wiki could
>> have a FAQ entry to prevent others from running into an open trap,
>> then I'd appreciate if you make it clear with code examples, so that
>> I can publish it.
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> OK, I changed my approach with some success.
>>>
>>> Instead of adding the listener and handling the conflict when the
>>> second client saves I now check the transaction in my save method.
>>> If the transaction is dirty and conflicted then I just rollback and
>>> commit. Now everything is useable, that is, I can then re-modify the
>>> objects and do a successful commit from client 1.
>>>
>>> Mark.
>>>
>>> Eike Stepper wrote:
>>>> Mark,
>>>>
>>>> I think this is the root cause. The transaction not being dirty is
>>>> most probably a followup problem because object state CONFLICT
>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>
>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>> RollbackTransition());
>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>
>>>> Please use the Introspector view to verify the state of the
>>>> conflicting objects and the transaction itself before and after the
>>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring
>>>> the transaction in a proper state after commit() and rollback():
>>>>
>>>> public void rollback(boolean remote)
>>>> {
>>>> try
>>>> {
>>>> if (!newResources.isEmpty())
>>>> {
>>>> for (CDOObject newResource : newResources.values())
>>>> {
>>>> removeObject(newResource.cdoID());
>>>> getResourceSet().getResources().remove(newResource);
>>>> }
>>>> }
>>>>
>>>> if (!newObjects.isEmpty())
>>>> {
>>>> for (CDOObject newObject : newObjects.values())
>>>> {
>>>> removeObject(newObject.cdoID());
>>>> }
>>>> }
>>>>
>>>> if (!dirtyObjects.isEmpty())
>>>> {
>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>> {
>>>>
>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>> remote);
>>>> }
>>>> }
>>>>
>>>> cleanUp();
>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>> fireEvent(new
>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>> idMappings));
>>>> }
>>>> catch (RuntimeException ex)
>>>> {
>>>> throw ex;
>>>> }
>>>> catch (Exception ex)
>>>> {
>>>> throw new TransactionException(ex);
>>>> }
>>>> }
>>>>
>>>> private void cleanUp()
>>>> {
>>>> newPackages = null;
>>>> newResources.clear();
>>>> newObjects.clear();
>>>> dirtyObjects.clear();
>>>> dirty = false;
>>>> conflict = false;
>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>> }
>>>>
>>>> BTW. I checked again that all the states have proper values all
>>>> over the process here.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>> not, it's a sign that the problem is in the client. There you can
>>>>>> use the Net4j Container view and the Net4j Introspector view to
>>>>>> click at runtime through the user interface elements down to the
>>>>>> core elements and browse their fields. May be this helps you
>>>>>> track it down further.
>>>>>>
>>>>>> From the log you should be able to locate an appropriate line
>>>>>> for a breakpoint to start debugging at. A high entry could be in
>>>>>> the CommitTransactionAction (if you use that to commit). A low
>>>>>> entry could be CDOTransactionImpl.commit() which is still before
>>>>>> the statemachine for particular objects is triggered.
>>>>>>
>>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>>> something to prepare the old transaction for use again after the
>>>>>>> rollback.??
>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>> should be non-dirty and all objects with newer remote version
>>>>>> should be proxies, all other objects should be clean.
>>>>>>
>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>> That is tests.model1 + CDO UI
>>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
>>>>>>
>>>>>> .
>>>>>>
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>> Mark Geib schrieb:
>>>>>>>>> Eike,
>>>>>>>>>
>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>
>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>> problem. After I do the rollback I can go ahead and modify the
>>>>>>>>> object and a commit succeeds. The problem is that the changes
>>>>>>>>> are not save in the database. That is, if I exit both clients
>>>>>>>>> and then restart only the first saved changes to the object
>>>>>>>>> are present. The changes made after the rollback and re-commit
>>>>>>>>> are lost.
>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>>> for me.
>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>
>>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>>> to) indicate a problem in the client, although I can't
>>>>>>>> reproduce it here. A bug in the server would be more likely if
>>>>>>>> the problem occurs after you restarted the server, but you
>>>>>>>> mention to only restart the clients. I mean, even if the server
>>>>>>>> would forget to save changes to the database, it would have the
>>>>>>>> most recent ones in its cache.
>>>>>>>>
>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>> that effect the results.?
>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>> it's rather unlikely.
>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>> database (I use the NOOPStore).
>>>>>>>> But I've worked many times through all your instructions with a
>>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate
>>>>>>>> CDO Server + 2 separate UI clients.
>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>
>>>>>>>> I fear we have only few options:
>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>> here and there)
>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>> ;-) )
>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eike Stepper
>>>>>>>> ----
>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612449 is a reply to message #102309] |
Fri, 09 November 2007 14:51 |
| Eclipse User |
|
|
|
Eike,
I am only concerned with API changes. I am trying to minimize the risk
of significant changes in a future release, when I want to use some new
feature. This is not a big deal now, just thought I would ask.
Have a good weekend,
Mark.
Eike Stepper wrote:
> Mark Geib schrieb:
>> Eike,
>>
>> I guess I was a bit confused that I could not do anything in the event
>> handler that effected the object state. It would seem that I should be
>> able to take some action there to handle the event, like doing a
>> rollback, etc. I understand that the state machine must control the
>> state.
>>
>> I do have a couple questions.
>>
>> o Can I tell what objects are deleted in the transaction.?? I can get
>> the dirty and new, be not the deleted.
> The deleted objects are those with
> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>
> If you think I should provide a convenience getter in CDOTransaction
> please open a feature request for CDO 0.8.
>
>> o Does it make sense to undo my command stack when ever I call
>> rollback on a transaction, to keep my GUI consistent with my model
>> objects.?? I am still working on this...
> No, I don't think so. Undo works but from a CDO framework perspective it
> is like the client application, it modifies the objects via normal
> EObject API and not via the CDOStore. As a result CDO can't distinguish
> between CommandStack access and normal client code access. The
> transaction will become dirty. I couldn't find a situation where this is
> dangerous for the data but it depends on what you want to achieve.
>
>> o Do you any kind of roadmap for CDO. I am planning to release my
>> system using CDO very soon and need some help on when to freeze the
>> CDO/Net4J versions. I had planned to use a real release of CDO when I
>> do my release so that I do not build and release something slightly
>> different than that provided on the eclipse site for CDO.
> Hmm, I don't have a written road map and CDO is currrently in a state
> where no very obvious things are missing. But I have some ideas and some
> are already documented:
> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>
>
> Note that a dozen of them or so are already implemented (due to a
> problem with the releng infra structure I can't move them to RESOLVED,
> Nick is working on that).
>
> Why are asking, do you want to consider some new features or are you
> afraid of coming API changes?
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
>>
>> Mark.
>>
>>
>>
>> Eike Stepper wrote:
>>> Mark,
>>>
>>> From your writing I get the impression that the cause was in your
>>> client code.
>>> I must admit that I don't have a clear picture of what was wrong and
>>> to what you changed it.
>>> If you say it was a silly fault, it's ok for me ;-)
>>> If you feel that the CDO API is not clear enough or the wiki could
>>> have a FAQ entry to prevent others from running into an open trap,
>>> then I'd appreciate if you make it clear with code examples, so that
>>> I can publish it.
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> OK, I changed my approach with some success.
>>>>
>>>> Instead of adding the listener and handling the conflict when the
>>>> second client saves I now check the transaction in my save method.
>>>> If the transaction is dirty and conflicted then I just rollback and
>>>> commit. Now everything is useable, that is, I can then re-modify the
>>>> objects and do a successful commit from client 1.
>>>>
>>>> Mark.
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark,
>>>>>
>>>>> I think this is the root cause. The transaction not being dirty is
>>>>> most probably a followup problem because object state CONFLICT
>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>
>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>> RollbackTransition());
>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>
>>>>> Please use the Introspector view to verify the state of the
>>>>> conflicting objects and the transaction itself before and after the
>>>>> rollback(). The CDOTransactionImpl.cleanUp() method should bring
>>>>> the transaction in a proper state after commit() and rollback():
>>>>>
>>>>> public void rollback(boolean remote)
>>>>> {
>>>>> try
>>>>> {
>>>>> if (!newResources.isEmpty())
>>>>> {
>>>>> for (CDOObject newResource : newResources.values())
>>>>> {
>>>>> removeObject(newResource.cdoID());
>>>>> getResourceSet().getResources().remove(newResource);
>>>>> }
>>>>> }
>>>>>
>>>>> if (!newObjects.isEmpty())
>>>>> {
>>>>> for (CDOObject newObject : newObjects.values())
>>>>> {
>>>>> removeObject(newObject.cdoID());
>>>>> }
>>>>> }
>>>>>
>>>>> if (!dirtyObjects.isEmpty())
>>>>> {
>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>> {
>>>>>
>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>> remote);
>>>>> }
>>>>> }
>>>>>
>>>>> cleanUp();
>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>> fireEvent(new
>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>> idMappings));
>>>>> }
>>>>> catch (RuntimeException ex)
>>>>> {
>>>>> throw ex;
>>>>> }
>>>>> catch (Exception ex)
>>>>> {
>>>>> throw new TransactionException(ex);
>>>>> }
>>>>> }
>>>>>
>>>>> private void cleanUp()
>>>>> {
>>>>> newPackages = null;
>>>>> newResources.clear();
>>>>> newObjects.clear();
>>>>> dirtyObjects.clear();
>>>>> dirty = false;
>>>>> conflict = false;
>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>> }
>>>>>
>>>>> BTW. I checked again that all the states have proper values all
>>>>> over the process here.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>> not, it's a sign that the problem is in the client. There you can
>>>>>>> use the Net4j Container view and the Net4j Introspector view to
>>>>>>> click at runtime through the user interface elements down to the
>>>>>>> core elements and browse their fields. May be this helps you
>>>>>>> track it down further.
>>>>>>>
>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>> for a breakpoint to start debugging at. A high entry could be in
>>>>>>> the CommitTransactionAction (if you use that to commit). A low
>>>>>>> entry could be CDOTransactionImpl.commit() which is still before
>>>>>>> the statemachine for particular objects is triggered.
>>>>>>>
>>>>>>>> Do I need to create a new transaction after the rollback, or do
>>>>>>>> something to prepare the old transaction for use again after the
>>>>>>>> rollback.??
>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>
>>>>>>> Have you also tried to verify it with purely CDO provided means?
>>>>>>> That is tests.model1 + CDO UI
>>>>>>> Just that we have an indication whether the issue occurs there, too.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
>>>>>>>
>>>>>>> .
>>>>>>>
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>> Eike,
>>>>>>>>>>
>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>
>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>> problem. After I do the rollback I can go ahead and modify the
>>>>>>>>>> object and a commit succeeds. The problem is that the changes
>>>>>>>>>> are not save in the database. That is, if I exit both clients
>>>>>>>>>> and then restart only the first saved changes to the object
>>>>>>>>>> are present. The changes made after the rollback and re-commit
>>>>>>>>>> are lost.
>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>> But I double checked your "new" scenario and it works perfectly
>>>>>>>>> for me.
>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>
>>>>>>>>> Another thought: What you describe here could (but doesn't need
>>>>>>>>> to) indicate a problem in the client, although I can't
>>>>>>>>> reproduce it here. A bug in the server would be more likely if
>>>>>>>>> the problem occurs after you restarted the server, but you
>>>>>>>>> mention to only restart the clients. I mean, even if the server
>>>>>>>>> would forget to save changes to the database, it would have the
>>>>>>>>> most recent ones in its cache.
>>>>>>>>>
>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>> that effect the results.?
>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>> it's rather unlikely.
>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>> But I've worked many times through all your instructions with a
>>>>>>>>> proper 4 process setup: Separate db (Derby+HSQLDB), separate
>>>>>>>>> CDO Server + 2 separate UI clients.
>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>
>>>>>>>>> I fear we have only few options:
>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>> here and there)
>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>> ;-) )
>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eike Stepper
>>>>>>>>> ----
>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612452 is a reply to message #102322] |
Fri, 09 November 2007 15:09 |
| Eclipse User |
|
|
|
Mark,
As my "longest" user I can offer to discuss all API changes with you
before I apply them.
BTW. I'll be on vacation from 11/18 to 12/12, so if you have other
important questions...
Enjoy your weekend, too
Eike Stepper
----
http://wiki.eclipse.org/?title=CDO
http://wiki.eclipse.org/?title=Net4j
Mark Geib schrieb:
> Eike,
>
> I am only concerned with API changes. I am trying to minimize the risk
> of significant changes in a future release, when I want to use some
> new feature. This is not a big deal now, just thought I would ask.
>
> Have a good weekend,
> Mark.
>
> Eike Stepper wrote:
>> Mark Geib schrieb:
>>> Eike,
>>>
>>> I guess I was a bit confused that I could not do anything in the
>>> event handler that effected the object state. It would seem that I
>>> should be able to take some action there to handle the event, like
>>> doing a rollback, etc. I understand that the state machine must
>>> control the state.
>>>
>>> I do have a couple questions.
>>>
>>> o Can I tell what objects are deleted in the transaction.?? I can
>>> get the dirty and new, be not the deleted.
>> The deleted objects are those with
>> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>>
>> If you think I should provide a convenience getter in CDOTransaction
>> please open a feature request for CDO 0.8.
>>
>>> o Does it make sense to undo my command stack when ever I call
>>> rollback on a transaction, to keep my GUI consistent with my model
>>> objects.?? I am still working on this...
>> No, I don't think so. Undo works but from a CDO framework perspective
>> it is like the client application, it modifies the objects via normal
>> EObject API and not via the CDOStore. As a result CDO can't
>> distinguish between CommandStack access and normal client code
>> access. The transaction will become dirty. I couldn't find a
>> situation where this is dangerous for the data but it depends on what
>> you want to achieve.
>>
>>> o Do you any kind of roadmap for CDO. I am planning to release my
>>> system using CDO very soon and need some help on when to freeze the
>>> CDO/Net4J versions. I had planned to use a real release of CDO when
>>> I do my release so that I do not build and release something
>>> slightly different than that provided on the eclipse site for CDO.
>> Hmm, I don't have a written road map and CDO is currrently in a state
>> where no very obvious things are missing. But I have some ideas and
>> some are already documented:
>> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>>
>>
>> Note that a dozen of them or so are already implemented (due to a
>> problem with the releng infra structure I can't move them to
>> RESOLVED, Nick is working on that).
>>
>> Why are asking, do you want to consider some new features or are you
>> afraid of coming API changes?
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/?title=CDO
>> http://wiki.eclipse.org/?title=Net4j
>>
>>
>>
>>>
>>> Mark.
>>>
>>>
>>>
>>> Eike Stepper wrote:
>>>> Mark,
>>>>
>>>> From your writing I get the impression that the cause was in your
>>>> client code.
>>>> I must admit that I don't have a clear picture of what was wrong
>>>> and to what you changed it.
>>>> If you say it was a silly fault, it's ok for me ;-)
>>>> If you feel that the CDO API is not clear enough or the wiki could
>>>> have a FAQ entry to prevent others from running into an open trap,
>>>> then I'd appreciate if you make it clear with code examples, so
>>>> that I can publish it.
>>>>
>>>> Regards,
>>>> Eike Stepper
>>>> ----
>>>> http://wiki.eclipse.org/?title=CDO
>>>> http://wiki.eclipse.org/?title=Net4j
>>>>
>>>>
>>>>
>>>> Mark Geib schrieb:
>>>>> Eike,
>>>>>
>>>>> OK, I changed my approach with some success.
>>>>>
>>>>> Instead of adding the listener and handling the conflict when the
>>>>> second client saves I now check the transaction in my save method.
>>>>> If the transaction is dirty and conflicted then I just rollback
>>>>> and commit. Now everything is useable, that is, I can then
>>>>> re-modify the objects and do a successful commit from client 1.
>>>>>
>>>>> Mark.
>>>>>
>>>>> Eike Stepper wrote:
>>>>>> Mark,
>>>>>>
>>>>>> I think this is the root cause. The transaction not being dirty
>>>>>> is most probably a followup problem because object state CONFLICT
>>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>>
>>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>>> RollbackTransition());
>>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>>
>>>>>> Please use the Introspector view to verify the state of the
>>>>>> conflicting objects and the transaction itself before and after
>>>>>> the rollback(). The CDOTransactionImpl.cleanUp() method should
>>>>>> bring the transaction in a proper state after commit() and
>>>>>> rollback():
>>>>>>
>>>>>> public void rollback(boolean remote)
>>>>>> {
>>>>>> try
>>>>>> {
>>>>>> if (!newResources.isEmpty())
>>>>>> {
>>>>>> for (CDOObject newResource : newResources.values())
>>>>>> {
>>>>>> removeObject(newResource.cdoID());
>>>>>> getResourceSet().getResources().remove(newResource);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> if (!newObjects.isEmpty())
>>>>>> {
>>>>>> for (CDOObject newObject : newObjects.values())
>>>>>> {
>>>>>> removeObject(newObject.cdoID());
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> if (!dirtyObjects.isEmpty())
>>>>>> {
>>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>>> {
>>>>>>
>>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>>> remote);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> cleanUp();
>>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>>> fireEvent(new
>>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>>> idMappings));
>>>>>> }
>>>>>> catch (RuntimeException ex)
>>>>>> {
>>>>>> throw ex;
>>>>>> }
>>>>>> catch (Exception ex)
>>>>>> {
>>>>>> throw new TransactionException(ex);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> private void cleanUp()
>>>>>> {
>>>>>> newPackages = null;
>>>>>> newResources.clear();
>>>>>> newObjects.clear();
>>>>>> dirtyObjects.clear();
>>>>>> dirty = false;
>>>>>> conflict = false;
>>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>>> }
>>>>>>
>>>>>> BTW. I checked again that all the states have proper values all
>>>>>> over the process here.
>>>>>>
>>>>>> Regards,
>>>>>> Eike Stepper
>>>>>> ----
>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mark Geib schrieb:
>>>>>>> Eike,
>>>>>>>
>>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>>
>>>>>>> Mark.
>>>>>>>
>>>>>>> Eike Stepper wrote:
>>>>>>>> Mark Geib schrieb:
>>>>>>>>> Eike,
>>>>>>>>>
>>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>>> not, it's a sign that the problem is in the client. There you
>>>>>>>> can use the Net4j Container view and the Net4j Introspector
>>>>>>>> view to click at runtime through the user interface elements
>>>>>>>> down to the core elements and browse their fields. May be this
>>>>>>>> helps you track it down further.
>>>>>>>>
>>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>>> for a breakpoint to start debugging at. A high entry could be
>>>>>>>> in the CommitTransactionAction (if you use that to commit). A
>>>>>>>> low entry could be CDOTransactionImpl.commit() which is still
>>>>>>>> before the statemachine for particular objects is triggered.
>>>>>>>>
>>>>>>>>> Do I need to create a new transaction after the rollback, or
>>>>>>>>> do something to prepare the old transaction for use again
>>>>>>>>> after the rollback.??
>>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>>
>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>> Just that we have an indication whether the issue occurs there,
>>>>>>>> too.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Eike Stepper
>>>>>>>> ----
>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>
>>>>>>>>
>>>>>>>> .
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Mark.
>>>>>>>>>
>>>>>>>>> Eike Stepper wrote:
>>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>>> Eike,
>>>>>>>>>>>
>>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>>
>>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>>> problem. After I do the rollback I can go ahead and modify
>>>>>>>>>>> the object and a commit succeeds. The problem is that the
>>>>>>>>>>> changes are not save in the database. That is, if I exit
>>>>>>>>>>> both clients and then restart only the first saved changes
>>>>>>>>>>> to the object are present. The changes made after the
>>>>>>>>>>> rollback and re-commit are lost.
>>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>>> But I double checked your "new" scenario and it works
>>>>>>>>>> perfectly for me.
>>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>>
>>>>>>>>>> Another thought: What you describe here could (but doesn't
>>>>>>>>>> need to) indicate a problem in the client, although I can't
>>>>>>>>>> reproduce it here. A bug in the server would be more likely
>>>>>>>>>> if the problem occurs after you restarted the server, but you
>>>>>>>>>> mention to only restart the clients. I mean, even if the
>>>>>>>>>> server would forget to save changes to the database, it would
>>>>>>>>>> have the most recent ones in its cache.
>>>>>>>>>>
>>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>>> that effect the results.?
>>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>>> it's rather unlikely.
>>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>>> But I've worked many times through all your instructions with
>>>>>>>>>> a proper 4 process setup: Separate db (Derby+HSQLDB),
>>>>>>>>>> separate CDO Server + 2 separate UI clients.
>>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>>
>>>>>>>>>> I fear we have only few options:
>>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>>> here and there)
>>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>>> ;-) )
>>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Eike Stepper
>>>>>>>>>> ----
>>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>>
|
|
|
| Re: [CDO] how to handle object update conflicts [message #612455 is a reply to message #102335] |
Fri, 09 November 2007 15:09 |
| Eclipse User |
|
|
|
Eike,
Thanks for the info. Knowing that I will plan to have a release done by
the end of the day on the 17th, well the 16th.
Also, thanks for the offer regarding API changes, but no need for that.
Mark.
Eike Stepper wrote:
> Mark,
>
> As my "longest" user I can offer to discuss all API changes with you
> before I apply them.
> BTW. I'll be on vacation from 11/18 to 12/12, so if you have other
> important questions...
>
> Enjoy your weekend, too
> Eike Stepper
> ----
> http://wiki.eclipse.org/?title=CDO
> http://wiki.eclipse.org/?title=Net4j
>
>
>
> Mark Geib schrieb:
>> Eike,
>>
>> I am only concerned with API changes. I am trying to minimize the risk
>> of significant changes in a future release, when I want to use some
>> new feature. This is not a big deal now, just thought I would ask.
>>
>> Have a good weekend,
>> Mark.
>>
>> Eike Stepper wrote:
>>> Mark Geib schrieb:
>>>> Eike,
>>>>
>>>> I guess I was a bit confused that I could not do anything in the
>>>> event handler that effected the object state. It would seem that I
>>>> should be able to take some action there to handle the event, like
>>>> doing a rollback, etc. I understand that the state machine must
>>>> control the state.
>>>>
>>>> I do have a couple questions.
>>>>
>>>> o Can I tell what objects are deleted in the transaction.?? I can
>>>> get the dirty and new, be not the deleted.
>>> The deleted objects are those with
>>> cdoState()==DIRTY && cdoRevision().getContainerID()==CDOID.NULL
>>>
>>> If you think I should provide a convenience getter in CDOTransaction
>>> please open a feature request for CDO 0.8.
>>>
>>>> o Does it make sense to undo my command stack when ever I call
>>>> rollback on a transaction, to keep my GUI consistent with my model
>>>> objects.?? I am still working on this...
>>> No, I don't think so. Undo works but from a CDO framework perspective
>>> it is like the client application, it modifies the objects via normal
>>> EObject API and not via the CDOStore. As a result CDO can't
>>> distinguish between CommandStack access and normal client code
>>> access. The transaction will become dirty. I couldn't find a
>>> situation where this is dangerous for the data but it depends on what
>>> you want to achieve.
>>>
>>>> o Do you any kind of roadmap for CDO. I am planning to release my
>>>> system using CDO very soon and need some help on when to freeze the
>>>> CDO/Net4J versions. I had planned to use a real release of CDO when
>>>> I do my release so that I do not build and release something
>>>> slightly different than that provided on the eclipse site for CDO.
>>> Hmm, I don't have a written road map and CDO is currrently in a state
>>> where no very obvious things are missing. But I have some ideas and
>>> some are already documented:
>>> https://bugs.eclipse.org/bugs/buglist.cgi?product=EMFT&c omponent=CDO&bug_status=NEW&bug_status=ASSIGNED& bug_status=REOPENED&order=bugs.bug_status,bugs.target_mi lestone,bugs.bug_id&query_format=advanced
>>>
>>>
>>> Note that a dozen of them or so are already implemented (due to a
>>> problem with the releng infra structure I can't move them to
>>> RESOLVED, Nick is working on that).
>>>
>>> Why are asking, do you want to consider some new features or are you
>>> afraid of coming API changes?
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/?title=CDO
>>> http://wiki.eclipse.org/?title=Net4j
>>>
>>>
>>>
>>>>
>>>> Mark.
>>>>
>>>>
>>>>
>>>> Eike Stepper wrote:
>>>>> Mark,
>>>>>
>>>>> From your writing I get the impression that the cause was in your
>>>>> client code.
>>>>> I must admit that I don't have a clear picture of what was wrong
>>>>> and to what you changed it.
>>>>> If you say it was a silly fault, it's ok for me ;-)
>>>>> If you feel that the CDO API is not clear enough or the wiki could
>>>>> have a FAQ entry to prevent others from running into an open trap,
>>>>> then I'd appreciate if you make it clear with code examples, so
>>>>> that I can publish it.
>>>>>
>>>>> Regards,
>>>>> Eike Stepper
>>>>> ----
>>>>> http://wiki.eclipse.org/?title=CDO
>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>
>>>>>
>>>>>
>>>>> Mark Geib schrieb:
>>>>>> Eike,
>>>>>>
>>>>>> OK, I changed my approach with some success.
>>>>>>
>>>>>> Instead of adding the listener and handling the conflict when the
>>>>>> second client saves I now check the transaction in my save method.
>>>>>> If the transaction is dirty and conflicted then I just rollback
>>>>>> and commit. Now everything is useable, that is, I can then
>>>>>> re-modify the objects and do a successful commit from client 1.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>>> Eike Stepper wrote:
>>>>>>> Mark,
>>>>>>>
>>>>>>> I think this is the root cause. The transaction not being dirty
>>>>>>> is most probably a followup problem because object state CONFLICT
>>>>>>> can't be left via event WRITE, see CDOStateMachine:
>>>>>>>
>>>>>>> init(CDOState.CONFLICT, CDOEvent.ATTACH, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.DETACH, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.READ, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.WRITE, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.INVALIDATE, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.RELOAD, new ReloadTransition());
>>>>>>> init(CDOState.CONFLICT, CDOEvent.COMMIT, IGNORE);
>>>>>>> init(CDOState.CONFLICT, CDOEvent.ROLLBACK, new
>>>>>>> RollbackTransition());
>>>>>>> init(CDOState.CONFLICT, CDOEvent.FINALIZE_ATTACH, IGNORE);
>>>>>>>
>>>>>>> Please use the Introspector view to verify the state of the
>>>>>>> conflicting objects and the transaction itself before and after
>>>>>>> the rollback(). The CDOTransactionImpl.cleanUp() method should
>>>>>>> bring the transaction in a proper state after commit() and
>>>>>>> rollback():
>>>>>>>
>>>>>>> public void rollback(boolean remote)
>>>>>>> {
>>>>>>> try
>>>>>>> {
>>>>>>> if (!newResources.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject newResource : newResources.values())
>>>>>>> {
>>>>>>> removeObject(newResource.cdoID());
>>>>>>> getResourceSet().getResources().remove(newResource);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> if (!newObjects.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject newObject : newObjects.values())
>>>>>>> {
>>>>>>> removeObject(newObject.cdoID());
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> if (!dirtyObjects.isEmpty())
>>>>>>> {
>>>>>>> for (CDOObject dirtyObject : dirtyObjects.values())
>>>>>>> {
>>>>>>>
>>>>>>> CDOStateMachine.INSTANCE.rollback((InternalCDOObject)dirtyOb ject,
>>>>>>> remote);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> cleanUp();
>>>>>>> Map<CDOID, CDOID> idMappings = Collections.emptyMap();
>>>>>>> fireEvent(new
>>>>>>> FinishedEvent(CDOTransactionFinishedEvent.Type.ROLLED_BACK,
>>>>>>> idMappings));
>>>>>>> }
>>>>>>> catch (RuntimeException ex)
>>>>>>> {
>>>>>>> throw ex;
>>>>>>> }
>>>>>>> catch (Exception ex)
>>>>>>> {
>>>>>>> throw new TransactionException(ex);
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> private void cleanUp()
>>>>>>> {
>>>>>>> newPackages = null;
>>>>>>> newResources.clear();
>>>>>>> newObjects.clear();
>>>>>>> dirtyObjects.clear();
>>>>>>> dirty = false;
>>>>>>> conflict = false;
>>>>>>> nextTemporaryID = INITIAL_TEMPORARY_ID;
>>>>>>> }
>>>>>>>
>>>>>>> BTW. I checked again that all the states have proper values all
>>>>>>> over the process here.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Eike Stepper
>>>>>>> ----
>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mark Geib schrieb:
>>>>>>>> Eike,
>>>>>>>>
>>>>>>>> I also see in the logs that the state of the object is CONFLICT
>>>>>>>> rather than DIRTY prior to the commit which does nothing.
>>>>>>>>
>>>>>>>> Mark.
>>>>>>>>
>>>>>>>> Eike Stepper wrote:
>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>> Eike,
>>>>>>>>>>
>>>>>>>>>> I have looking at the logs carefully. After I do the rollback,
>>>>>>>>>> then modify the same object that was conflicted, then do a
>>>>>>>>>> commit I do not see any traffice for the save/commit. I do not
>>>>>>>>>> get the event for the start of the commit or end of the commit.
>>>>>>>>> There should be traffic if the transaction is really dirty. If
>>>>>>>>> not, it's a sign that the problem is in the client. There you
>>>>>>>>> can use the Net4j Container view and the Net4j Introspector
>>>>>>>>> view to click at runtime through the user interface elements
>>>>>>>>> down to the core elements and browse their fields. May be this
>>>>>>>>> helps you track it down further.
>>>>>>>>>
>>>>>>>>> From the log you should be able to locate an appropriate line
>>>>>>>>> for a breakpoint to start debugging at. A high entry could be
>>>>>>>>> in the CommitTransactionAction (if you use that to commit). A
>>>>>>>>> low entry could be CDOTransactionImpl.commit() which is still
>>>>>>>>> before the statemachine for particular objects is triggered.
>>>>>>>>>
>>>>>>>>>> Do I need to create a new transaction after the rollback, or
>>>>>>>>>> do something to prepare the old transaction for use again
>>>>>>>>>> after the rollback.??
>>>>>>>>> No, rollback() is sufficient. After that call the transaction
>>>>>>>>> should be non-dirty and all objects with newer remote version
>>>>>>>>> should be proxies, all other objects should be clean.
>>>>>>>>>
>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>> Just that we have an indication whether the issue occurs there,
>>>>>>>>> too.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Eike Stepper
>>>>>>>>> ----
>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Mark.
>>>>>>>>>>
>>>>>>>>>> Eike Stepper wrote:
>>>>>>>>>>> Mark Geib schrieb:
>>>>>>>>>>>> Eike,
>>>>>>>>>>>>
>>>>>>>>>>>> I am not at work for about an hour or so to try your test.
>>>>>>>>>>>>
>>>>>>>>>>>> However, maybe I was not clear in the desciption of my
>>>>>>>>>>>> problem. After I do the rollback I can go ahead and modify
>>>>>>>>>>>> the object and a commit succeeds. The problem is that the
>>>>>>>>>>>> changes are not save in the database. That is, if I exit
>>>>>>>>>>>> both clients and then restart only the first saved changes
>>>>>>>>>>>> to the object are present. The changes made after the
>>>>>>>>>>>> rollback and re-commit are lost.
>>>>>>>>>>> Ok, I really misinterpreted it first.
>>>>>>>>>>> But I double checked your "new" scenario and it works
>>>>>>>>>>> perfectly for me.
>>>>>>>>>>> Have you also tried to verify it with purely CDO provided
>>>>>>>>>>> means? That is tests.model1 + CDO UI
>>>>>>>>>>>
>>>>>>>>>>> Another thought: What you describe here could (but doesn't
>>>>>>>>>>> need to) indicate a problem in the client, although I can't
>>>>>>>>>>> reproduce it here. A bug in the server would be more likely
>>>>>>>>>>> if the problem occurs after you restarted the server, but you
>>>>>>>>>>> mention to only restart the clients. I mean, even if the
>>>>>>>>>>> server would forget to save changes to the database, it would
>>>>>>>>>>> have the most recent ones in its cache.
>>>>>>>>>>>
>>>>>>>>>>>> Am I correct in assuming that your test runs in a single
>>>>>>>>>>>> process.? That seems to be a different environment that I am
>>>>>>>>>>>> running, with two instances on two different machines. Could
>>>>>>>>>>>> that effect the results.?
>>>>>>>>>>> In general I can't exclude such effect for 100% but I think
>>>>>>>>>>> it's rather unlikely.
>>>>>>>>>>> The JUnit tests run in a single process and even without real
>>>>>>>>>>> database (I use the NOOPStore).
>>>>>>>>>>> But I've worked many times through all your instructions with
>>>>>>>>>>> a proper 4 process setup: Separate db (Derby+HSQLDB),
>>>>>>>>>>> separate CDO Server + 2 separate UI clients.
>>>>>>>>>>> Not a single sign that something is wrong.
>>>>>>>>>>>
>>>>>>>>>>> I fear we have only few options:
>>>>>>>>>>> 1) You get it by looking at your logs (maybe add some traces
>>>>>>>>>>> here and there)
>>>>>>>>>>> 2) You get it with the debugger (which is your friend, i know
>>>>>>>>>>> ;-) )
>>>>>>>>>>> 3) You send me your application via email and I debug it for you
>>>>>>>>>>> 4) You have an idea that I didn't have
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Eike Stepper
>>>>>>>>>>> ----
>>>>>>>>>>> http://wiki.eclipse.org/?title=CDO
>>>>>>>>>>> http://wiki.eclipse.org/?title=Net4j
>>>>>>>>>>>
|
|
|
Goto Forum:
Current Time: Thu Jun 05 12:31:11 EDT 2025
Powered by FUDForum. Page generated in 0.34551 seconds |
Home