Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » [cdo][0.8.0]
[cdo][0.8.0] [message #104867] Mon, 17 December 2007 23:50 Go to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
hi EIke,

I have a question.

How do you see interaction of objects in application using different
repository. Repositories could be in the same server or 2 differents server
?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.
Re: [cdo][0.8.0] Multiple repository on different servers [message #104871 is a reply to message #104867] Tue, 18 December 2007 03:27 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
"Simon McDuff" <smcduff@hotmail.com> a
Re: [cdo][0.8.0] Multiple repository on different servers [message #104877 is a reply to message #104871] Tue, 18 December 2007 11:25 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------070503040908030604000200
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Simon McDuff schrieb:
> "Simon McDuff" <smcduff@hotmail.com> a
Re: [cdo][0.8.0] [message #104880 is a reply to message #104867] Tue, 18 December 2007 11:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Simon,

One of the most basic and essential guarantees that CDO gives to the
user is a *consistent object graph in the repository*. With
inter-repository references we would clearly corrupt this assumption!
Consequently it'd be quite probable that I'd reject a respective feature
request.

I don't want to keep secret that I already rejected other feature
requests that would have corrupted the above assumption: A friend of
mine proposed to add a possibility to switch single objects back to
previous revisions to be able to overwrite remote updates. Inconsistent
object graphs are inherent to that feature!

On the other hand I can understand the desire to use multiple
repositories in a user application. The key term to the solution is IMHO
"user application". The best way to implement something that the user
application can use like inter-repository references without
compromising the consistent object graphs in any repository is the
following:

- Add derived reference features to your model(s)
- Have something in your model(s) and in your application that enables
the implementation of the derived features to deresolve to the target
objects in a different session. The model doesn't necessarily be
modified for this because you could use the CDOID, but could be if you
don't want to use it. Your application needs to be able to lookup a
session, given a persistable key. And that's the main reason why the CDO
framework can't deliver this function. CDO generally has no idea how the
application associates the various concepts, namely repository and
session. Nor can the CDO framework know how to handle
DeresolveExceptions (due to inconsistent inter-repository object graph).

If you can come up with a proposal how the above solution can be moved
into the framework I'd be more than happy ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> hi EIke,
>
> I have a question.
>
> How do you see interaction of objects in application using different
> repository. Repositories could be in the same server or 2 differents server
> ?
>
> Here an example :
> ObjectA FROM REPOA
> ObjectB FROM REPOB
>
> Add a link between ObjectA to ObjectB
>
> commit().
>
> It should be done transparently.
>
>
>
Re: [cdo][0.8.0] [message #104882 is a reply to message #104880] Tue, 18 December 2007 11:53 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Eike Stepper schrieb:
> Hi Simon,
>
> One of the most basic and essential guarantees that CDO gives to the
> user is a *consistent object graph in the repository*. With
> inter-repository references we would clearly corrupt this assumption!
> Consequently it'd be quite probable that I'd reject a respective
> feature request.
>
> I don't want to keep secret that I already rejected other feature
> requests that would have corrupted the above assumption: A friend of
> mine proposed to add a possibility to switch single objects back to
> previous revisions to be able to overwrite remote updates.
> Inconsistent object graphs are inherent to that feature!
>
> On the other hand I can understand the desire to use multiple
> repositories in a user application. The key term to the solution is
> IMHO "user application". The best way to implement something that the
> user application can use like inter-repository references without
> compromising the consistent object graphs in any repository is the
> following:
>
> - Add derived reference features to your model(s)
> - Have something in your model(s) and in your application that enables
> the implementation of the derived features to deresolve to the target
> objects in a different session. The model doesn't necessarily be
> modified for this because you could use the CDOID, but could be if you
> don't want to use it. Your application needs to be able to lookup a
> session
Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

> , given a persistable key. And that's the main reason why the CDO
> framework can't deliver this function. CDO generally has no idea how
> the application associates the various concepts, namely repository and
> session.
Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

> Nor can the CDO framework know how to handle DeresolveExceptions (due
> to inconsistent inter-repository object graph).
>
> If you can come up with a proposal how the above solution can be moved
> into the framework I'd be more than happy ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Simon McDuff schrieb:
>> hi EIke,
>>
>> I have a question.
>>
>> How do you see interaction of objects in application using different
>> repository. Repositories could be in the same server or 2 differents
>> server ?
>>
>> Here an example :
>> ObjectA FROM REPOA
>> ObjectB FROM REPOB
>>
>> Add a link between ObjectA to ObjectB
>>
>> commit().
>>
>> It should be done transparently.
>>
>>
Re: [cdo][0.8.0] Multiple repository on different servers [message #104884 is a reply to message #104877] Tue, 18 December 2007 12:02 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_00AF_01C84143.E9DABD20
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

I would like to link objects from one repository to the other ?

Two Differents repositories are configure like the following:

Repo1
Oracle

Repo2
Derby

My model is shared between these 2 repo.
I have object1 (from repo1) and object2(from repo 2)

I would like to do the following

object1.setXXXX(object2);

commit();

Do you see that possible ?





hi EIke,

I have a question.

How do you see interaction of objects in application using different=20
repository. Repositories could be in the same server or 2 differents=20
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.

=20


------=_NextPart_000_00AF_01C84143.E9DABD20
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I would like to link objects from one =
repository to=20
the other ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Two Differents repositories are =
configure like the=20
following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Repo1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Oracle</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Repo2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Derby</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My model is shared between these 2=20
repo.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have object1 (from repo1) and =
object2(from repo=20
2)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I would like to do the =
following</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>object1.setXXXX(object2);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>commit();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Do&nbsp;you see that possible =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<BLOCKQUOTE cite=3Dmid:fk7enm$1lg$1@build.eclipse.org type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">hi EIke,

I have a question.

How do you see interaction of objects in application using different=20
repository. Repositories could be in the same server or 2 differents=20
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.

</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AF_01C84143.E9DABD20--
Re: [cdo][0.8.0] [message #104888 is a reply to message #104882] Tue, 18 December 2007 12:08 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I thought that we could do a 2 phases commit to ensure the graph is correct.

The first phase will return MAPPING ID from temp to good one.

The phase 2 will adjust references and commit();

In my JPA interface, will be good to have a 2 phases commit since I will be
able to integrate my entityManager to a XATransaction.

I think it is the only things I will need to have to be able to do
cross-store... and keeps the integrity of the graph.

What you think ?


"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8cbi$oem$5@build.eclipse.org...
> Eike Stepper schrieb:
>> Hi Simon,
>>
>> One of the most basic and essential guarantees that CDO gives to the user
>> is a *consistent object graph in the repository*. With inter-repository
>> references we would clearly corrupt this assumption! Consequently it'd be
>> quite probable that I'd reject a respective feature request.
>>
>> I don't want to keep secret that I already rejected other feature
>> requests that would have corrupted the above assumption: A friend of mine
>> proposed to add a possibility to switch single objects back to previous
>> revisions to be able to overwrite remote updates. Inconsistent object
>> graphs are inherent to that feature!
>>
>> On the other hand I can understand the desire to use multiple
>> repositories in a user application. The key term to the solution is IMHO
>> "user application". The best way to implement something that the user
>> application can use like inter-repository references without compromising
>> the consistent object graphs in any repository is the following:
>>
>> - Add derived reference features to your model(s)
>> - Have something in your model(s) and in your application that enables
>> the implementation of the derived features to deresolve to the target
>> objects in a different session. The model doesn't necessarily be modified
>> for this because you could use the CDOID, but could be if you don't want
>> to use it. Your application needs to be able to lookup a session
> Correction: Not a CDOSession but a CDOView, because we need to lookup an
> object and not a revision!
>
>> , given a persistable key. And that's the main reason why the CDO
>> framework can't deliver this function. CDO generally has no idea how the
>> application associates the various concepts, namely repository and
>> session.
> Correction: Not a CDOSession but a CDOView, because we need to lookup an
> object and not a revision!
>
>> Nor can the CDO framework know how to handle DeresolveExceptions (due to
>> inconsistent inter-repository object graph).
>>
>> If you can come up with a proposal how the above solution can be moved
>> into the framework I'd be more than happy ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Simon McDuff schrieb:
>>> hi EIke,
>>>
>>> I have a question.
>>>
>>> How do you see interaction of objects in application using different
>>> repository. Repositories could be in the same server or 2 differents
>>> server ?
>>>
>>> Here an example :
>>> ObjectA FROM REPOA
>>> ObjectB FROM REPOB
>>>
>>> Add a link between ObjectA to ObjectB
>>>
>>> commit().
>>>
>>> It should be done transparently.
>>>
>>>
Re: [cdo][0.8.0] Multiple repository on different servers [message #104893 is a reply to message #104884] Tue, 18 December 2007 14:35 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Please see the other response...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> I would like to link objects from one repository to the other ?
>
> Two Differents repositories are configure like the following:
>
> Repo1
> Oracle
>
> Repo2
> Derby
>
> My model is shared between these 2 repo.
> I have object1 (from repo1) and object2(from repo 2)
>
> I would like to do the following
>
> object1.setXXXX(object2);
>
> commit();
>
> Do you see that possible ?
>
>
>
>
>>> hi EIke,
>>>
>>> I have a question.
>>>
>>> How do you see interaction of objects in application using different
>>> repository. Repositories could be in the same server or 2 differents
>>> server ?
>>>
>>> Here an example :
>>> ObjectA FROM REPOA
>>> ObjectB FROM REPOB
>>>
>>> Add a link between ObjectA to ObjectB
>>>
>>> commit().
>>>
>>> It should be done transparently.
>>>
>>>
>>
>>
>>
>
Re: [cdo][0.8.0] [message #104896 is a reply to message #104888] Tue, 18 December 2007 14:51 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------060001010000040101090106
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
> I thought that we could do a 2 phases commit to ensure the graph is correct.
>
I also thought about XA support several times, though not in the context
of inter-repository references.

> The first phase will return MAPPING ID from temp to good one.
> The phase 2 will adjust references and commit();
>
With respect to XA support I'm not sure that it is that easy.
But a good patch could easily convince me ;-)

Aside from the XA discussion what exactly do you mean with "adjust
references"?

I believe that in general it is not feasible to ensure consistency in
arbitrary inter-repository object graphs! The only way to do so would be
to force all clients to use the same set of repos. If at any time only
parts of the repos set (or a single repo) is accessed there is potential
to create partially consistent graphs that are not consistent in the
bigger set.

> In my JPA interface, will be good to have a 2 phases commit since I will be
> able to integrate my entityManager to a XATransaction.
>
Although I still doubt that the changes are trivial I think XA support
would be a good complement to CDOs native transaction.

> I think it is the only things I will need to have to be able to do
> cross-store... and keeps the integrity of the graph.
>
> What you think ?
>
Summary:
- XA support, good thing. Note that XA support doesn't implicitely solve
the technical problem "framework managed inter-repo references"!
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8cbi$oem$5@build.eclipse.org...
>
>> Eike Stepper schrieb:
>>
>>> Hi Simon,
>>>
>>> One of the most basic and essential guarantees that CDO gives to the user
>>> is a *consistent object graph in the repository*. With inter-repository
>>> references we would clearly corrupt this assumption! Consequently it'd be
>>> quite probable that I'd reject a respective feature request.
>>>
>>> I don't want to keep secret that I already rejected other feature
>>> requests that would have corrupted the above assumption: A friend of mine
>>> proposed to add a possibility to switch single objects back to previous
>>> revisions to be able to overwrite remote updates. Inconsistent object
>>> graphs are inherent to that feature!
>>>
>>> On the other hand I can understand the desire to use multiple
>>> repositories in a user application. The key term to the solution is IMHO
>>> "user application". The best way to implement something that the user
>>> application can use like inter-repository references without compromising
>>> the consistent object graphs in any repository is the following:
>>>
>>> - Add derived reference features to your model(s)
>>> - Have something in your model(s) and in your application that enables
>>> the implementation of the derived features to deresolve to the target
>>> objects in a different session. The model doesn't necessarily be modified
>>> for this because you could use the CDOID, but could be if you don't want
>>> to use it. Your application needs to be able to lookup a session
>>>
>> Correction: Not a CDOSession but a CDOView, because we need to lookup an
>> object and not a revision!
>>
>>
>>> , given a persistable key. And that's the main reason why the CDO
>>> framework can't deliver this function. CDO generally has no idea how the
>>> application associates the various concepts, namely repository and
>>> session.
>>>
>> Correction: Not a CDOSession but a CDOView, because we need to lookup an
>> object and not a revision!
>>
>>
>>> Nor can the CDO framework know how to handle DeresolveExceptions (due to
>>> inconsistent inter-repository object graph).
>>>
>>> If you can come up with a proposal how the above solution can be moved
>>> into the framework I'd be more than happy ;-)
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Simon McDuff schrieb:
>>>
>>>> hi EIke,
>>>>
>>>> I have a question.
>>>>
>>>> How do you see interaction of objects in application using different
>>>> repository. Repositories could be in the same server or 2 differents
>>>> server ?
>>>>
>>>> Here an example :
>>>> ObjectA FROM REPOA
>>>> ObjectB FROM REPOB
>>>>
>>>> Add a link between ObjectA to ObjectB
>>>>
>>>> commit().
>>>>
>>>> It should be done transparently.
>>>>
>>>>
>>>>
>
>
>

--------------060001010000040101090106
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">
Simon McDuff schrieb:
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">I thought that we could do a 2 phases commit to ensure the graph is correct.
</pre>
</blockquote>
I also thought about XA support several times, though not in the
context of inter-repository references.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">The first phase will return MAPPING ID from temp to good one.
The phase 2 will adjust references and commit();
</pre>
</blockquote>
With respect to XA support I'm not sure that it is that easy. <br>
But a good patch could easily convince me ;-)<br>
<br>
Aside from the XA discussion what exactly do you mean with "adjust
references"?<br>
<br>
I believe that in general it is not feasible to ensure consistency in
arbitrary inter-repository object graphs! The only way to do so would
be to force all clients to use the same set of repos. If at any time
only parts of the repos set (or a single repo) is accessed there is
potential to create partially consistent graphs that are not consistent
in the bigger set.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">In my JPA interface, will be good to have a 2 phases commit since I will be
able to integrate my entityManager to a XATransaction.
</pre>
</blockquote>
Although I still doubt that the changes are trivial I think XA support
would be a good complement to CDOs native transaction.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">I think it is the only things I will need to have to be able to do
cross-store... and keeps the integrity of the graph.

What you think ?
</pre>
</blockquote>
Summary:<br>
- XA support, good thing. Note that XA support doesn't implicitely
solve the technical problem "framework managed inter-repo references"!<br>
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">

"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8cbi$oem$5@build.eclipse.org">news:fk8cbi$oem$5@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Eike Stepper schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Simon,

One of the most basic and essential guarantees that CDO gives to the user
is a *consistent object graph in the repository*. With inter-repository
references we would clearly corrupt this assumption! Consequently it'd be
quite probable that I'd reject a respective feature request.

I don't want to keep secret that I already rejected other feature
requests that would have corrupted the above assumption: A friend of mine
proposed to add a possibility to switch single objects back to previous
revisions to be able to overwrite remote updates. Inconsistent object
graphs are inherent to that feature!

On the other hand I can understand the desire to use multiple
repositories in a user application. The key term to the solution is IMHO
"user application". The best way to implement something that the user
application can use like inter-repository references without compromising
the consistent object graphs in any repository is the following:

- Add derived reference features to your model(s)
- Have something in your model(s) and in your application that enables
the implementation of the derived features to deresolve to the target
objects in a different session. The model doesn't necessarily be modified
for this because you could use the CDOID, but could be if you don't want
to use it. Your application needs to be able to lookup a session
</pre>
</blockquote>
<pre wrap="">Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

</pre>
<blockquote type="cite">
<pre wrap="">, given a persistable key. And that's the main reason why the CDO
framework can't deliver this function. CDO generally has no idea how the
application associates the various concepts, namely repository and
session.
</pre>
</blockquote>
<pre wrap="">Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

</pre>
<blockquote type="cite">
<pre wrap="">Nor can the CDO framework know how to handle DeresolveExceptions (due to
inconsistent inter-repository object graph).

If you can come up with a proposal how the above solution can be moved
into the framework I'd be more than happy ;-)

Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>



Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">hi EIke,

I have a question.

How do you see interaction of objects in application using different
repository. Repositories could be in the same server or 2 differents
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.


</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------060001010000040101090106--
Re: [cdo][0.8.0] [message #104901 is a reply to message #104896] Tue, 18 December 2007 15:24 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
At some point I will come up with a patch(don't know if it will be a good
patch)


>>Aside from the XA discussion what exactly do you mean with "adjust
>>references"?
Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. They will need to
adjust their reference after sending the request.


Summary:
- XA support, good thing. Note that XA support doesn't implicitely solve
the technical problem "framework managed inter-repo references"!
[SIMON] I believe that if you are part of a XA transaction .. it will
ensure consistency between multiple CDORepos
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.
[SIMON] If each application are doing always the same trick to handle
multiple repos.. why not put it part of the framework.

Regards,
Eike Stepper
Re: [cdo][0.8.0] [message #104908 is a reply to message #104901] Tue, 18 December 2007 15:47 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon McDuff schrieb:
>
> At some point I will come up with a patch(don't know if it will be a
> good patch)
Great!

>> Aside from the XA discussion what exactly do you mean with "adjust
>> references"?
> Let say I have objectA(from repoA) and objectB(From repoB)
> objectA.setXXX(objectB);
> objectB.setXXX(objectA);
> Both of them need to know the id of the other objects.
Important: id plus session!

> They will need to adjust their reference after sending the request.
I still don't know what you mean ;-(

> Summary:
> - XA support, good thing. Note that XA support doesn't implicitely
> solve the technical problem "framework managed inter-repo references"!
> [SIMON] I believe that if you are part of a XA transaction .. it will
> ensure consistency between multiple CDORepos
The important word here is "if"! The framework will never be able to
ensure that a repository is always modified through a stable set of
multiple sessions.

> - Framework managed inter-repo references, not a good thing for the
> reasons I gave in the previous postings. I vote for the application
> managed approach.
> [SIMON] If each application are doing always the same trick to handle
> multiple repos.. why not put it part of the framework.
I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at all.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: [cdo][0.8.0] [message #104914 is a reply to message #104908] Tue, 18 December 2007 16:08 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Aside from the XA discussion what exactly do you mean with "adjust
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects.
Important: id plus session!


They will need to adjust their reference after sending the request.

I still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph.
- Each repos could save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will be
done through JPA.
- When you load an object, to resolve it it will go through the
resourceset.. where it will connect automatically to the right CDOSEssion
to get to the data.

I don't see where it is not feasible.
Re: [cdo][0.8.0] [message #104923 is a reply to message #104914] Tue, 18 December 2007 16:28 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for
the proxy that an arbitrary client can reconsrtuct that right session?

But even more important your scenario always predicts that all clients
go through the same set of repositories as members of the XA. Would you
vote for denying access to a single repository only because it was used
in a XA commit?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> Aside from the XA discussion what exactly do you mean with "adjust
> references"?
>
> Let say I have objectA(from repoA) and objectB(From repoB)
> objectA.setXXX(objectB);
> objectB.setXXX(objectA);
> Both of them need to know the id of the other objects. Important: id
> plus session!
>
>
> They will need to adjust their reference after sending the request.
> I still don't know what you mean ;-(
> [SIMON]Both repo aren't necessarly in the same server. Could be at
> two differences places.
>
> I'd say you were right if it was feasible *and* appropriate.
> Up to now I argued that it's not feasible (see above) but I'd
> appreciate to discuss the appropriateness if you can proof that it's
> feasible at all.
>
> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
> After that it is easy!!
> - You have XA to ensure the integrity of the graph. - Each repos could
> save PROXY(URI)
> - JPA will do the mapping between them.
> - Each resource will be associate with a repo. This mapping will
> be done through JPA.
> - When you load an object, to resolve it it will go through the
> resourceset.. where it will connect automatically to the right
> CDOSEssion to get to the data.
>
> I don't see where it is not feasible.
>
>
>
>
>
>
>
Re: [cdo][0.8.0] [message #104930 is a reply to message #104923] Tue, 18 December 2007 16:44 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8ses$vt0$4@build.eclipse.org...
> Simon,
>
> I think my main point is another one:
> It relates a bit to the last sentence of you "where it will connect
> automatically to the right CDOSEssion".
> Can you please explain how you plan to persist enough information for the
> proxy that an arbitrary client can reconsrtuct that right session?
I will use URI of the object. In the URI it contains : Resource + object
identifier.

So when you will try to load that objects from its URI.. it will go the
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific
resource could be assocaite with any CDOTransaction.


>
> But even more important your scenario always predicts that all clients go
> through the same set of repositories as members of the XA. Would you vote
> for denying access to a single repository only because it was used in a XA
> commit?
I don't understand your question. Can you clarify your thoughts ? I will try
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same repo
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register in
the resourceset. At this point it doesn't know if it is a XA transaction.
We will add XA to ensure the integrity of the graph.

>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Simon McDuff schrieb:
>> Aside from the XA discussion what exactly do you mean with "adjust
>> references"?
>>
>> Let say I have objectA(from repoA) and objectB(From repoB)
>> objectA.setXXX(objectB);
>> objectB.setXXX(objectA);
>> Both of them need to know the id of the other objects. Important: id plus
>> session!
>>
>>
>> They will need to adjust their reference after sending the request. I
>> still don't know what you mean ;-(
>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>> differences places.
>>
>> I'd say you were right if it was feasible *and* appropriate.
>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>> to discuss the appropriateness if you can proof that it's feasible at
>> all.
>>
>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>> After that it is easy!!
>> - You have XA to ensure the integrity of the graph. - Each repos could
>> save PROXY(URI)
>> - JPA will do the mapping between them.
>> - Each resource will be associate with a repo. This mapping will be
>> done through JPA.
>> - When you load an object, to resolve it it will go through the
>> resourceset.. where it will connect automatically to the right CDOSEssion
>> to get to the data.
>>
>> I don't see where it is not feasible.
>>
>>
>>
>>
>>
>>
>>
Re: [cdo][0.8.0] [message #104935 is a reply to message #104930] Tue, 18 December 2007 17:56 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------090200080707080506080505
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8ses$vt0$4@build.eclipse.org...
>
>> Simon,
>>
>> I think my main point is another one:
>> It relates a bit to the last sentence of you "where it will connect
>> automatically to the right CDOSEssion".
>> Can you please explain how you plan to persist enough information for the
>> proxy that an arbitrary client can reconsrtuct that right session?
>>
> I will use URI of the object. In the URI it contains : Resource + object
> identifier.
>
> So when you will try to load that objects from its URI.. it will go the
> resourset.. and load it from there.
> You will have register your resource in the resourset. SO the specific
> resource could be assocaite with any CDOTransaction.
>
Currently in CDO there is a 1:1 association between resource set and
transaction. Would you like to change that?

>> But even more important your scenario always predicts that all clients go
>> through the same set of repositories as members of the XA. Would you vote
>> for denying access to a single repository only because it was used in a XA
>> commit?
>>
> I don't understand your question. Can you clarify your thoughts ? I will try
> to answer.. but not sure if it will answer your question.
> XA point of view is .. It doesn't matter if objects are from the same repo
> or different repo. It should always work.... in both cases.
> My scenario predicts that I will go the repositories that was register in
> the resourceset. At this point it doesn't know if it is a XA transaction.
> We will add XA to ensure the integrity of the graph.
>
I'll try to say it with an example (given we had inter-repo refs):

- Client 1 uses a distributed transaction to commit into 2 repositories
repoA and repoB. An inter-repo ref [R] from repoA -> repoB is part of
the transaction.
- Some time later client 2 uses a normal transaction/view to navigate
the object graph of repoA. When it tries to dereference [R] it comes to
an InconsistentObjectGraphException.

>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Simon McDuff schrieb:
>>
>>> Aside from the XA discussion what exactly do you mean with "adjust
>>> references"?
>>>
>>> Let say I have objectA(from repoA) and objectB(From repoB)
>>> objectA.setXXX(objectB);
>>> objectB.setXXX(objectA);
>>> Both of them need to know the id of the other objects. Important: id plus
>>> session!
>>>
>>>
>>> They will need to adjust their reference after sending the request. I
>>> still don't know what you mean ;-(
>>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>>> differences places.
>>>
>>> I'd say you were right if it was feasible *and* appropriate.
>>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>>> to discuss the appropriateness if you can proof that it's feasible at
>>> all.
>>>
>>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>>> After that it is easy!!
>>> - You have XA to ensure the integrity of the graph. - Each repos could
>>> save PROXY(URI)
>>> - JPA will do the mapping between them.
>>> - Each resource will be associate with a repo. This mapping will be
>>> done through JPA.
>>> - When you load an object, to resolve it it will go through the
>>> resourceset.. where it will connect automatically to the right CDOSEssion
>>> to get to the data.
>>>
>>> I don't see where it is not feasible.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------090200080707080506080505
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">
Simon McDuff schrieb:
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<pre wrap="">"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8ses$vt0$4@build.eclipse.org">news:fk8ses$vt0$4@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for the
proxy that an arbitrary client can reconsrtuct that right session?
</pre>
</blockquote>
<pre wrap=""><!---->I will use URI of the object. In the URI it contains : Resource + object
identifier.

So when you will try to load that objects from its URI.. it will go the
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific
resource could be assocaite with any CDOTransaction.
</pre>
</blockquote>
Currently in CDO there is a 1:1 association between resource set and
transaction. Would you like to change that?<br>
<br>
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">But even more important your scenario always predicts that all clients go
through the same set of repositories as members of the XA. Would you vote
for denying access to a single repository only because it was used in a XA
commit?
</pre>
</blockquote>
<pre wrap=""><!---->I don't understand your question. Can you clarify your thoughts ? I will try
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same repo
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register in
the resourceset. At this point it doesn't know if it is a XA transaction.
We will add XA to ensure the integrity of the graph.
</pre>
</blockquote>
I'll try to say it with an example (given we had inter-repo refs):<br>
<br>
- Client 1 uses a distributed transaction to commit into 2 repositories
repoA and repoB. An inter-repo ref [R] from repoA -&gt; repoB is part
of the transaction.<br>
- Some time later client 2 uses a normal transaction/view to navigate
the object graph of repoA. When it tries to dereference [R] it comes to
an InconsistentObjectGraphException.<br>
<br>
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>



Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Aside from the XA discussion what exactly do you mean with "adjust
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id plus
session!


They will need to adjust their reference after sending the request. I
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will be
done through JPA.
- When you load an object, to resolve it it will go through the
resourceset.. where it will connect automatically to the right CDOSEssion
to get to the data.

I don't see where it is not feasible.







</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------090200080707080506080505--
Re: [cdo][0.8.0] [message #104942 is a reply to message #104935] Tue, 18 December 2007 19:42 Go to previous messageGo to next message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_0112_01C84184.3FE59C40
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable


"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fk91k7$g26$1@build.eclipse.org...
Simon McDuff schrieb:=20
"Eike Stepper" <stepper@sympedia.de> wrote in message=20
news:fk8ses$vt0$4@build.eclipse.org...
Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect=20
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for =
the=20
proxy that an arbitrary client can reconsrtuct that right session?
I will use URI of the object. In the URI it contains : Resource + =
object=20
identifier.

So when you will try to load that objects from its URI.. it will go the=20
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific=20
resource could be assocaite with any CDOTransaction.
Currently in CDO there is a 1:1 association between resource set and =
transaction. Would you like to change that?
Yes, It would be more a resource attach to a transaction. DO you see =
any problems ?


But even more important your scenario always predicts that all clients =
go=20
through the same set of repositories as members of the XA. Would you =
vote=20
for denying access to a single repository only because it was used in a =
XA=20
commit?
I don't understand your question. Can you clarify your thoughts ? I =
will try=20
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same =
repo=20
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register =
in=20
the resourceset. At this point it doesn't know if it is a XA =
transaction.
We will add XA to ensure the integrity of the graph.
I'll try to say it with an example (given we had inter-repo refs):

- Client 1 uses a distributed transaction to commit into 2 =
repositories repoA and repoB. An inter-repo ref [R] from repoA -> repoB =
is part of the transaction.
- Some time later client 2 uses a normal transaction/view to navigate =
the object graph of repoA. When it tries to dereference [R] it comes to =
an InconsistentObjectGraphException.

Yes we had no choice.
It should react exactly the same way as we were doing crossreference =
between resources in EMF.. The resource XXX isn't reachable..=20
Right ?



Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
Aside from the XA discussion what exactly do you mean with "adjust=20
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id =
plus=20
session!


They will need to adjust their reference after sending the request. I=20
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two=20
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate =

to discuss the appropriateness if you can proof that it's feasible at=20
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could=20
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will =
be=20
done through JPA.
- When you load an object, to resolve it it will go through the=20
resourceset.. where it will connect automatically to the right =
CDOSEssion=20
to get to the data.

I don't see where it is not feasible.







=20


------=_NextPart_000_0112_01C84184.3FE59C40
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" &lt;<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>&gt; wrote =
in message=20
<A=20
=
href=3D"news:fk91k7$g26$1@build.eclipse.org">news:fk91k7$g26$1@build.ecli=
pse.org</A>...</DIV>Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">"Eike Stepper" <A =
class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</A> =
wrote in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:fk8ses$vt0$4@build.eclipse.org">news:fk8ses$vt0$4@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect=20
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for =
the=20
proxy that an arbitrary client can reconsrtuct that right session?
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->I will use URI of the =
object. In the URI it contains : Resource + object=20
identifier.

So when you will try to load that objects from its URI.. it will go the=20
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific=20
resource could be assocaite with any CDOTransaction.
</PRE></BLOCKQUOTE>
<DIV>Currently in CDO there is a 1:1 association between resource set =
and=20
transaction. Would you like to change that?</DIV>
<DIV>Yes, It would be more a resource attach to a transaction. DO you =
see any=20
problems ?<BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">But even more important =
your scenario always predicts that all clients go=20
through the same set of repositories as members of the XA. Would you =
vote=20
for denying access to a single repository only because it was used in a =
XA=20
commit?
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->I don't understand your =
question. Can you clarify your thoughts ? I will try=20
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same =
repo=20
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register =
in=20
the resourceset. At this point it doesn't know if it is a XA =
transaction.
We will add XA to ensure the integrity of the graph.
</PRE></BLOCKQUOTE>
<DIV>I'll try to say it with an example (given we had inter-repo=20
refs):<BR><BR>- Client 1 uses a distributed transaction to commit into =
2=20
repositories repoA and repoB. An inter-repo ref [R] from repoA -&gt; =
repoB is=20
part of the transaction.<BR>- Some time later client 2 uses a normal=20
transaction/view to navigate the object graph of repoA. When it tries =
to=20
dereference [R] it comes to an InconsistentObjectGraphException.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes we had no choice.<FONT face=3DArial size=3D2></FONT></DIV>
<DIV>It should react exactly the same way as we were doing =
crossreference=20
between resources in EMF.. The resource XXX isn't reachable.. </DIV>
<DIV>Right ?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR>&nbsp;</DIV>
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D""> </PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Regards,
Eike Stepper
----
<A class=3Dmoz-txt-link-freetext =
href=3D"http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</A>
<A class=3Dmoz-txt-link-freetext =
href=3D"http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</A>



Simon McDuff schrieb:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Aside from the XA =
discussion what exactly do you mean with "adjust=20
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id =
plus=20
session!


They will need to adjust their reference after sending the request. I=20
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two=20
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate =

to discuss the appropriateness if you can proof that it's feasible at=20
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could=20
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will =
be=20
done through JPA.
- When you load an object, to resolve it it will go through the=20
resourceset.. where it will connect automatically to the right =
CDOSEssion=20
to get to the data.

I don't see where it is not feasible.







</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0112_01C84184.3FE59C40--
Re: [cdo][0.8.0] [message #104954 is a reply to message #104942] Wed, 19 December 2007 05:27 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

This is a multi-part message in MIME format.
--------------010007090709010508090108
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fk91k7$g26$1@build.eclipse.org...
> Simon McDuff schrieb:
>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>> news:fk8ses$vt0$4@build.eclipse.org...
>>
>>> Simon,
>>>
>>> I think my main point is another one:
>>> It relates a bit to the last sentence of you "where it will connect
>>> automatically to the right CDOSEssion".
>>> Can you please explain how you plan to persist enough information for the
>>> proxy that an arbitrary client can reconsrtuct that right session?
>>>
>> I will use URI of the object. In the URI it contains : Resource + object
>> identifier.
>>
>> So when you will try to load that objects from its URI.. it will go the
>> resourset.. and load it from there.
>> You will have register your resource in the resourset. SO the specific
>> resource could be assocaite with any CDOTransaction.
>>
> Currently in CDO there is a 1:1 association between resource set
> and transaction. Would you like to change that?
> Yes, It would be more a resource attach to a transaction. DO you
> see any problems ?
>
I do see a lot of technical issues although.that alone doesn't prevent
from an eventual solution ;-)
I do see a major shift of paradigm as well.

You know that I'm generally not against technical challenges and
interesting new features but I still believe that this undertaking would
have a major impact on the existing concepts and solutions. This has at
least two consequences for me (and you):

1) Before digging into code of an eventual patch (or even creating such
a patch) I'd rather like to see something like a feasibility studie with
a detailed spec of the problem, a detailed spec of the suggested
solution and a detailed impact analysis. I know that thos would much
easier if there was a detailed spec of the current solution. But your
previous feature requests (btw. with cool results!) and the expectable
issues with the large code base could be blamed for the minor progress
I'm achieving with the documentation ;-) May be this is the point where
I'm finally pushed to write a detailed technical spec of the whole CDO
system...

2) This change could not be published as a normal I-build. It would
force the creation of a new branch. Absolutely doable but a lot of
effort, too. If you want to start prototyping I strongly recommend that
you do that in a separate workspace (your local branch).

>
>>> But even more important your scenario always predicts that all clients go
>>> through the same set of repositories as members of the XA. Would you vote
>>> for denying access to a single repository only because it was used in a XA
>>> commit?
>>>
>> I don't understand your question. Can you clarify your thoughts ? I will try
>> to answer.. but not sure if it will answer your question.
>> XA point of view is .. It doesn't matter if objects are from the same repo
>> or different repo. It should always work.... in both cases.
>> My scenario predicts that I will go the repositories that was register in
>> the resourceset. At this point it doesn't know if it is a XA transaction.
>> We will add XA to ensure the integrity of the graph.
>>
> I'll try to say it with an example (given we had inter-repo refs):
>
> - Client 1 uses a distributed transaction to commit into 2
> repositories repoA and repoB. An inter-repo ref [R] from repoA ->
> repoB is part of the transaction.
> - Some time later client 2 uses a normal transaction/view to
> navigate the object graph of repoA. When it tries to dereference
> [R] it comes to an InconsistentObjectGraphException.
>
> Yes we had no choice.
> It should react exactly the same way as we were doing
> crossreference between resources in EMF.. The resource XXX isn't
> reachable..
> Right ?
>
No, this is clearly not according to the current requirements (settled
years ago and stabilized through lots of experience with CDO). But
before we start to disput on selected technical details I'd really
suggest that we (mainly you) start to describe the whole solution.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j





>
>
>
>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Simon McDuff schrieb:
>>>
>>>> Aside from the XA discussion what exactly do you mean with "adjust
>>>> references"?
>>>>
>>>> Let say I have objectA(from repoA) and objectB(From repoB)
>>>> objectA.setXXX(objectB);
>>>> objectB.setXXX(objectA);
>>>> Both of them need to know the id of the other objects. Important: id plus
>>>> session!
>>>>
>>>>
>>>> They will need to adjust their reference after sending the request. I
>>>> still don't know what you mean ;-(
>>>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>>>> differences places.
>>>>
>>>> I'd say you were right if it was feasible *and* appropriate.
>>>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>>>> to discuss the appropriateness if you can proof that it's feasible at
>>>> all.
>>>>
>>>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>>>> After that it is easy!!
>>>> - You have XA to ensure the integrity of the graph. - Each repos could
>>>> save PROXY(URI)
>>>> - JPA will do the mapping between them.
>>>> - Each resource will be associate with a repo. This mapping will be
>>>> done through JPA.
>>>> - When you load an object, to resolve it it will go through the
>>>> resourceset.. where it will connect automatically to the right CDOSEssion
>>>> to get to the data.
>>>>
>>>> I don't see where it is not feasible.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

--------------010007090709010508090108
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!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">
Simon McDuff schrieb:
<blockquote cite="mid:fk97rm$9qv$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type"
content="text/html;charset=ISO-8859-15">
<meta content="MSHTML 6.00.2900.3199" name="GENERATOR">
<style></style>
<div>
Re: [cdo][0.8.0] [message #104961 is a reply to message #104942] Wed, 19 December 2007 05:42 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Simon,

Without giving any guarantee on how much time I can spend on this issue
I've file two separate enhancements requests and cc'ed you:

Support inter-repository references:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402

Support distributed transactions:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213403

Both are P5 to reflect that I currently prefer to work on things like
the exception handling that you proposed ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j
Re: [cdo][0.8.0] Multiple repository on different servers [message #612861 is a reply to message #104867] Tue, 18 December 2007 03:27 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
"Simon McDuff" <smcduff@hotmail.com> a
Re: [cdo][0.8.0] Multiple repository on different servers [message #612868 is a reply to message #104871] Tue, 18 December 2007 11:25 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------070503040908030604000200
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit

Simon McDuff schrieb:
> "Simon McDuff" <smcduff@hotmail.com> a


Re: [cdo][0.8.0] [message #612869 is a reply to message #104867] Tue, 18 December 2007 11:50 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Hi Simon,

One of the most basic and essential guarantees that CDO gives to the
user is a *consistent object graph in the repository*. With
inter-repository references we would clearly corrupt this assumption!
Consequently it'd be quite probable that I'd reject a respective feature
request.

I don't want to keep secret that I already rejected other feature
requests that would have corrupted the above assumption: A friend of
mine proposed to add a possibility to switch single objects back to
previous revisions to be able to overwrite remote updates. Inconsistent
object graphs are inherent to that feature!

On the other hand I can understand the desire to use multiple
repositories in a user application. The key term to the solution is IMHO
"user application". The best way to implement something that the user
application can use like inter-repository references without
compromising the consistent object graphs in any repository is the
following:

- Add derived reference features to your model(s)
- Have something in your model(s) and in your application that enables
the implementation of the derived features to deresolve to the target
objects in a different session. The model doesn't necessarily be
modified for this because you could use the CDOID, but could be if you
don't want to use it. Your application needs to be able to lookup a
session, given a persistable key. And that's the main reason why the CDO
framework can't deliver this function. CDO generally has no idea how the
application associates the various concepts, namely repository and
session. Nor can the CDO framework know how to handle
DeresolveExceptions (due to inconsistent inter-repository object graph).

If you can come up with a proposal how the above solution can be moved
into the framework I'd be more than happy ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> hi EIke,
>
> I have a question.
>
> How do you see interaction of objects in application using different
> repository. Repositories could be in the same server or 2 differents server
> ?
>
> Here an example :
> ObjectA FROM REPOA
> ObjectB FROM REPOB
>
> Add a link between ObjectA to ObjectB
>
> commit().
>
> It should be done transparently.
>
>
>


Re: [cdo][0.8.0] [message #612871 is a reply to message #104880] Tue, 18 December 2007 11:53 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Eike Stepper schrieb:
> Hi Simon,
>
> One of the most basic and essential guarantees that CDO gives to the
> user is a *consistent object graph in the repository*. With
> inter-repository references we would clearly corrupt this assumption!
> Consequently it'd be quite probable that I'd reject a respective
> feature request.
>
> I don't want to keep secret that I already rejected other feature
> requests that would have corrupted the above assumption: A friend of
> mine proposed to add a possibility to switch single objects back to
> previous revisions to be able to overwrite remote updates.
> Inconsistent object graphs are inherent to that feature!
>
> On the other hand I can understand the desire to use multiple
> repositories in a user application. The key term to the solution is
> IMHO "user application". The best way to implement something that the
> user application can use like inter-repository references without
> compromising the consistent object graphs in any repository is the
> following:
>
> - Add derived reference features to your model(s)
> - Have something in your model(s) and in your application that enables
> the implementation of the derived features to deresolve to the target
> objects in a different session. The model doesn't necessarily be
> modified for this because you could use the CDOID, but could be if you
> don't want to use it. Your application needs to be able to lookup a
> session
Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

> , given a persistable key. And that's the main reason why the CDO
> framework can't deliver this function. CDO generally has no idea how
> the application associates the various concepts, namely repository and
> session.
Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

> Nor can the CDO framework know how to handle DeresolveExceptions (due
> to inconsistent inter-repository object graph).
>
> If you can come up with a proposal how the above solution can be moved
> into the framework I'd be more than happy ;-)
>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Simon McDuff schrieb:
>> hi EIke,
>>
>> I have a question.
>>
>> How do you see interaction of objects in application using different
>> repository. Repositories could be in the same server or 2 differents
>> server ?
>>
>> Here an example :
>> ObjectA FROM REPOA
>> ObjectB FROM REPOB
>>
>> Add a link between ObjectA to ObjectB
>>
>> commit().
>>
>> It should be done transparently.
>>
>>


Re: [cdo][0.8.0] Multiple repository on different servers [message #612874 is a reply to message #104877] Tue, 18 December 2007 12:02 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_00AF_01C84143.E9DABD20
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

I would like to link objects from one repository to the other ?

Two Differents repositories are configure like the following:

Repo1
Oracle

Repo2
Derby

My model is shared between these 2 repo.
I have object1 (from repo1) and object2(from repo 2)

I would like to do the following

object1.setXXXX(object2);

commit();

Do you see that possible ?





hi EIke,

I have a question.

How do you see interaction of objects in application using different=20
repository. Repositories could be in the same server or 2 differents=20
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.

=20


------=_NextPart_000_00AF_01C84143.E9DABD20
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I would like to link objects from one =
repository to=20
the other ?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Two Differents repositories are =
configure like the=20
following:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Repo1</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Oracle</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Repo2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Derby</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>My model is shared between these 2=20
repo.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I have object1 (from repo1) and =
object2(from repo=20
2)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I would like to do the =
following</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>object1.setXXXX(object2);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>commit();</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Do&nbsp;you see that possible =
?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<BLOCKQUOTE cite=3Dmid:fk7enm$1lg$1@build.eclipse.org type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">hi EIke,

I have a question.

How do you see interaction of objects in application using different=20
repository. Repositories could be in the same server or 2 differents=20
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.

</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00AF_01C84143.E9DABD20--
Re: [cdo][0.8.0] [message #612876 is a reply to message #104882] Tue, 18 December 2007 12:08 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
I thought that we could do a 2 phases commit to ensure the graph is correct.

The first phase will return MAPPING ID from temp to good one.

The phase 2 will adjust references and commit();

In my JPA interface, will be good to have a 2 phases commit since I will be
able to integrate my entityManager to a XATransaction.

I think it is the only things I will need to have to be able to do
cross-store... and keeps the integrity of the graph.

What you think ?


"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8cbi$oem$5@build.eclipse.org...
> Eike Stepper schrieb:
>> Hi Simon,
>>
>> One of the most basic and essential guarantees that CDO gives to the user
>> is a *consistent object graph in the repository*. With inter-repository
>> references we would clearly corrupt this assumption! Consequently it'd be
>> quite probable that I'd reject a respective feature request.
>>
>> I don't want to keep secret that I already rejected other feature
>> requests that would have corrupted the above assumption: A friend of mine
>> proposed to add a possibility to switch single objects back to previous
>> revisions to be able to overwrite remote updates. Inconsistent object
>> graphs are inherent to that feature!
>>
>> On the other hand I can understand the desire to use multiple
>> repositories in a user application. The key term to the solution is IMHO
>> "user application". The best way to implement something that the user
>> application can use like inter-repository references without compromising
>> the consistent object graphs in any repository is the following:
>>
>> - Add derived reference features to your model(s)
>> - Have something in your model(s) and in your application that enables
>> the implementation of the derived features to deresolve to the target
>> objects in a different session. The model doesn't necessarily be modified
>> for this because you could use the CDOID, but could be if you don't want
>> to use it. Your application needs to be able to lookup a session
> Correction: Not a CDOSession but a CDOView, because we need to lookup an
> object and not a revision!
>
>> , given a persistable key. And that's the main reason why the CDO
>> framework can't deliver this function. CDO generally has no idea how the
>> application associates the various concepts, namely repository and
>> session.
> Correction: Not a CDOSession but a CDOView, because we need to lookup an
> object and not a revision!
>
>> Nor can the CDO framework know how to handle DeresolveExceptions (due to
>> inconsistent inter-repository object graph).
>>
>> If you can come up with a proposal how the above solution can be moved
>> into the framework I'd be more than happy ;-)
>>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Simon McDuff schrieb:
>>> hi EIke,
>>>
>>> I have a question.
>>>
>>> How do you see interaction of objects in application using different
>>> repository. Repositories could be in the same server or 2 differents
>>> server ?
>>>
>>> Here an example :
>>> ObjectA FROM REPOA
>>> ObjectB FROM REPOB
>>>
>>> Add a link between ObjectA to ObjectB
>>>
>>> commit().
>>>
>>> It should be done transparently.
>>>
>>>
Re: [cdo][0.8.0] Multiple repository on different servers [message #612879 is a reply to message #104884] Tue, 18 December 2007 14:35 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Please see the other response...

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> I would like to link objects from one repository to the other ?
>
> Two Differents repositories are configure like the following:
>
> Repo1
> Oracle
>
> Repo2
> Derby
>
> My model is shared between these 2 repo.
> I have object1 (from repo1) and object2(from repo 2)
>
> I would like to do the following
>
> object1.setXXXX(object2);
>
> commit();
>
> Do you see that possible ?
>
>
>
>
>>> hi EIke,
>>>
>>> I have a question.
>>>
>>> How do you see interaction of objects in application using different
>>> repository. Repositories could be in the same server or 2 differents
>>> server ?
>>>
>>> Here an example :
>>> ObjectA FROM REPOA
>>> ObjectB FROM REPOB
>>>
>>> Add a link between ObjectA to ObjectB
>>>
>>> commit().
>>>
>>> It should be done transparently.
>>>
>>>
>>
>>
>>
>


Re: [cdo][0.8.0] [message #612881 is a reply to message #104888] Tue, 18 December 2007 14:51 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------060001010000040101090106
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
> I thought that we could do a 2 phases commit to ensure the graph is correct.
>
I also thought about XA support several times, though not in the context
of inter-repository references.

> The first phase will return MAPPING ID from temp to good one.
> The phase 2 will adjust references and commit();
>
With respect to XA support I'm not sure that it is that easy.
But a good patch could easily convince me ;-)

Aside from the XA discussion what exactly do you mean with "adjust
references"?

I believe that in general it is not feasible to ensure consistency in
arbitrary inter-repository object graphs! The only way to do so would be
to force all clients to use the same set of repos. If at any time only
parts of the repos set (or a single repo) is accessed there is potential
to create partially consistent graphs that are not consistent in the
bigger set.

> In my JPA interface, will be good to have a 2 phases commit since I will be
> able to integrate my entityManager to a XATransaction.
>
Although I still doubt that the changes are trivial I think XA support
would be a good complement to CDOs native transaction.

> I think it is the only things I will need to have to be able to do
> cross-store... and keeps the integrity of the graph.
>
> What you think ?
>
Summary:
- XA support, good thing. Note that XA support doesn't implicitely solve
the technical problem "framework managed inter-repo references"!
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


>
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8cbi$oem$5@build.eclipse.org...
>
>> Eike Stepper schrieb:
>>
>>> Hi Simon,
>>>
>>> One of the most basic and essential guarantees that CDO gives to the user
>>> is a *consistent object graph in the repository*. With inter-repository
>>> references we would clearly corrupt this assumption! Consequently it'd be
>>> quite probable that I'd reject a respective feature request.
>>>
>>> I don't want to keep secret that I already rejected other feature
>>> requests that would have corrupted the above assumption: A friend of mine
>>> proposed to add a possibility to switch single objects back to previous
>>> revisions to be able to overwrite remote updates. Inconsistent object
>>> graphs are inherent to that feature!
>>>
>>> On the other hand I can understand the desire to use multiple
>>> repositories in a user application. The key term to the solution is IMHO
>>> "user application". The best way to implement something that the user
>>> application can use like inter-repository references without compromising
>>> the consistent object graphs in any repository is the following:
>>>
>>> - Add derived reference features to your model(s)
>>> - Have something in your model(s) and in your application that enables
>>> the implementation of the derived features to deresolve to the target
>>> objects in a different session. The model doesn't necessarily be modified
>>> for this because you could use the CDOID, but could be if you don't want
>>> to use it. Your application needs to be able to lookup a session
>>>
>> Correction: Not a CDOSession but a CDOView, because we need to lookup an
>> object and not a revision!
>>
>>
>>> , given a persistable key. And that's the main reason why the CDO
>>> framework can't deliver this function. CDO generally has no idea how the
>>> application associates the various concepts, namely repository and
>>> session.
>>>
>> Correction: Not a CDOSession but a CDOView, because we need to lookup an
>> object and not a revision!
>>
>>
>>> Nor can the CDO framework know how to handle DeresolveExceptions (due to
>>> inconsistent inter-repository object graph).
>>>
>>> If you can come up with a proposal how the above solution can be moved
>>> into the framework I'd be more than happy ;-)
>>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Simon McDuff schrieb:
>>>
>>>> hi EIke,
>>>>
>>>> I have a question.
>>>>
>>>> How do you see interaction of objects in application using different
>>>> repository. Repositories could be in the same server or 2 differents
>>>> server ?
>>>>
>>>> Here an example :
>>>> ObjectA FROM REPOA
>>>> ObjectB FROM REPOB
>>>>
>>>> Add a link between ObjectA to ObjectB
>>>>
>>>> commit().
>>>>
>>>> It should be done transparently.
>>>>
>>>>
>>>>
>
>
>

--------------060001010000040101090106
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">
Simon McDuff schrieb:
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">I thought that we could do a 2 phases commit to ensure the graph is correct.
</pre>
</blockquote>
I also thought about XA support several times, though not in the
context of inter-repository references.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">The first phase will return MAPPING ID from temp to good one.
The phase 2 will adjust references and commit();
</pre>
</blockquote>
With respect to XA support I'm not sure that it is that easy. <br>
But a good patch could easily convince me ;-)<br>
<br>
Aside from the XA discussion what exactly do you mean with "adjust
references"?<br>
<br>
I believe that in general it is not feasible to ensure consistency in
arbitrary inter-repository object graphs! The only way to do so would
be to force all clients to use the same set of repos. If at any time
only parts of the repos set (or a single repo) is accessed there is
potential to create partially consistent graphs that are not consistent
in the bigger set.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">In my JPA interface, will be good to have a 2 phases commit since I will be
able to integrate my entityManager to a XATransaction.
</pre>
</blockquote>
Although I still doubt that the changes are trivial I think XA support
would be a good complement to CDOs native transaction.<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">I think it is the only things I will need to have to be able to do
cross-store... and keeps the integrity of the graph.

What you think ?
</pre>
</blockquote>
Summary:<br>
- XA support, good thing. Note that XA support doesn't implicitely
solve the technical problem "framework managed inter-repo references"!<br>
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.<br>
<br>
Regards,<br>
Eike Stepper<br>
----<br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a><br>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a><br>
<br>
<br>
<blockquote cite="mid:fk8d8k$7pa$1@build.eclipse.org" type="cite">
<pre wrap="">

"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8cbi$oem$5@build.eclipse.org">news:fk8cbi$oem$5@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Eike Stepper schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Simon,

One of the most basic and essential guarantees that CDO gives to the user
is a *consistent object graph in the repository*. With inter-repository
references we would clearly corrupt this assumption! Consequently it'd be
quite probable that I'd reject a respective feature request.

I don't want to keep secret that I already rejected other feature
requests that would have corrupted the above assumption: A friend of mine
proposed to add a possibility to switch single objects back to previous
revisions to be able to overwrite remote updates. Inconsistent object
graphs are inherent to that feature!

On the other hand I can understand the desire to use multiple
repositories in a user application. The key term to the solution is IMHO
"user application". The best way to implement something that the user
application can use like inter-repository references without compromising
the consistent object graphs in any repository is the following:

- Add derived reference features to your model(s)
- Have something in your model(s) and in your application that enables
the implementation of the derived features to deresolve to the target
objects in a different session. The model doesn't necessarily be modified
for this because you could use the CDOID, but could be if you don't want
to use it. Your application needs to be able to lookup a session
</pre>
</blockquote>
<pre wrap="">Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

</pre>
<blockquote type="cite">
<pre wrap="">, given a persistable key. And that's the main reason why the CDO
framework can't deliver this function. CDO generally has no idea how the
application associates the various concepts, namely repository and
session.
</pre>
</blockquote>
<pre wrap="">Correction: Not a CDOSession but a CDOView, because we need to lookup an
object and not a revision!

</pre>
<blockquote type="cite">
<pre wrap="">Nor can the CDO framework know how to handle DeresolveExceptions (due to
inconsistent inter-repository object graph).

If you can come up with a proposal how the above solution can be moved
into the framework I'd be more than happy ;-)

Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>



Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">hi EIke,

I have a question.

How do you see interaction of objects in application using different
repository. Repositories could be in the same server or 2 differents
server ?

Here an example :
ObjectA FROM REPOA
ObjectB FROM REPOB

Add a link between ObjectA to ObjectB

commit().

It should be done transparently.


</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------060001010000040101090106--


Re: [cdo][0.8.0] [message #612882 is a reply to message #104896] Tue, 18 December 2007 15:24 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
At some point I will come up with a patch(don't know if it will be a good
patch)


>>Aside from the XA discussion what exactly do you mean with "adjust
>>references"?
Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. They will need to
adjust their reference after sending the request.


Summary:
- XA support, good thing. Note that XA support doesn't implicitely solve
the technical problem "framework managed inter-repo references"!
[SIMON] I believe that if you are part of a XA transaction .. it will
ensure consistency between multiple CDORepos
- Framework managed inter-repo references, not a good thing for the
reasons I gave in the previous postings. I vote for the application
managed approach.
[SIMON] If each application are doing always the same trick to handle
multiple repos.. why not put it part of the framework.

Regards,
Eike Stepper
Re: [cdo][0.8.0] [message #612884 is a reply to message #104901] Tue, 18 December 2007 15:47 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon McDuff schrieb:
>
> At some point I will come up with a patch(don't know if it will be a
> good patch)
Great!

>> Aside from the XA discussion what exactly do you mean with "adjust
>> references"?
> Let say I have objectA(from repoA) and objectB(From repoB)
> objectA.setXXX(objectB);
> objectB.setXXX(objectA);
> Both of them need to know the id of the other objects.
Important: id plus session!

> They will need to adjust their reference after sending the request.
I still don't know what you mean ;-(

> Summary:
> - XA support, good thing. Note that XA support doesn't implicitely
> solve the technical problem "framework managed inter-repo references"!
> [SIMON] I believe that if you are part of a XA transaction .. it will
> ensure consistency between multiple CDORepos
The important word here is "if"! The framework will never be able to
ensure that a repository is always modified through a stable set of
multiple sessions.

> - Framework managed inter-repo references, not a good thing for the
> reasons I gave in the previous postings. I vote for the application
> managed approach.
> [SIMON] If each application are doing always the same trick to handle
> multiple repos.. why not put it part of the framework.
I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at all.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Re: [cdo][0.8.0] [message #612885 is a reply to message #104908] Tue, 18 December 2007 16:08 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
Aside from the XA discussion what exactly do you mean with "adjust
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects.
Important: id plus session!


They will need to adjust their reference after sending the request.

I still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph.
- Each repos could save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will be
done through JPA.
- When you load an object, to resolve it it will go through the
resourceset.. where it will connect automatically to the right CDOSEssion
to get to the data.

I don't see where it is not feasible.
Re: [cdo][0.8.0] [message #612886 is a reply to message #104914] Tue, 18 December 2007 16:28 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for
the proxy that an arbitrary client can reconsrtuct that right session?

But even more important your scenario always predicts that all clients
go through the same set of repositories as members of the XA. Would you
vote for denying access to a single repository only because it was used
in a XA commit?

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
> Aside from the XA discussion what exactly do you mean with "adjust
> references"?
>
> Let say I have objectA(from repoA) and objectB(From repoB)
> objectA.setXXX(objectB);
> objectB.setXXX(objectA);
> Both of them need to know the id of the other objects. Important: id
> plus session!
>
>
> They will need to adjust their reference after sending the request.
> I still don't know what you mean ;-(
> [SIMON]Both repo aren't necessarly in the same server. Could be at
> two differences places.
>
> I'd say you were right if it was feasible *and* appropriate.
> Up to now I argued that it's not feasible (see above) but I'd
> appreciate to discuss the appropriateness if you can proof that it's
> feasible at all.
>
> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
> After that it is easy!!
> - You have XA to ensure the integrity of the graph. - Each repos could
> save PROXY(URI)
> - JPA will do the mapping between them.
> - Each resource will be associate with a repo. This mapping will
> be done through JPA.
> - When you load an object, to resolve it it will go through the
> resourceset.. where it will connect automatically to the right
> CDOSEssion to get to the data.
>
> I don't see where it is not feasible.
>
>
>
>
>
>
>


Re: [cdo][0.8.0] [message #612888 is a reply to message #104923] Tue, 18 December 2007 16:44 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
"Eike Stepper" <stepper@sympedia.de> wrote in message
news:fk8ses$vt0$4@build.eclipse.org...
> Simon,
>
> I think my main point is another one:
> It relates a bit to the last sentence of you "where it will connect
> automatically to the right CDOSEssion".
> Can you please explain how you plan to persist enough information for the
> proxy that an arbitrary client can reconsrtuct that right session?
I will use URI of the object. In the URI it contains : Resource + object
identifier.

So when you will try to load that objects from its URI.. it will go the
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific
resource could be assocaite with any CDOTransaction.


>
> But even more important your scenario always predicts that all clients go
> through the same set of repositories as members of the XA. Would you vote
> for denying access to a single repository only because it was used in a XA
> commit?
I don't understand your question. Can you clarify your thoughts ? I will try
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same repo
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register in
the resourceset. At this point it doesn't know if it is a XA transaction.
We will add XA to ensure the integrity of the graph.

>
> Regards,
> Eike Stepper
> ----
> http://wiki.eclipse.org/CDO
> http://wiki.eclipse.org/Net4j
>
>
>
> Simon McDuff schrieb:
>> Aside from the XA discussion what exactly do you mean with "adjust
>> references"?
>>
>> Let say I have objectA(from repoA) and objectB(From repoB)
>> objectA.setXXX(objectB);
>> objectB.setXXX(objectA);
>> Both of them need to know the id of the other objects. Important: id plus
>> session!
>>
>>
>> They will need to adjust their reference after sending the request. I
>> still don't know what you mean ;-(
>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>> differences places.
>>
>> I'd say you were right if it was feasible *and* appropriate.
>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>> to discuss the appropriateness if you can proof that it's feasible at
>> all.
>>
>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>> After that it is easy!!
>> - You have XA to ensure the integrity of the graph. - Each repos could
>> save PROXY(URI)
>> - JPA will do the mapping between them.
>> - Each resource will be associate with a repo. This mapping will be
>> done through JPA.
>> - When you load an object, to resolve it it will go through the
>> resourceset.. where it will connect automatically to the right CDOSEssion
>> to get to the data.
>>
>> I don't see where it is not feasible.
>>
>>
>>
>>
>>
>>
>>
Re: [cdo][0.8.0] [message #612890 is a reply to message #104930] Tue, 18 December 2007 17:56 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------090200080707080506080505
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
> "Eike Stepper" <stepper@sympedia.de> wrote in message
> news:fk8ses$vt0$4@build.eclipse.org...
>
>> Simon,
>>
>> I think my main point is another one:
>> It relates a bit to the last sentence of you "where it will connect
>> automatically to the right CDOSEssion".
>> Can you please explain how you plan to persist enough information for the
>> proxy that an arbitrary client can reconsrtuct that right session?
>>
> I will use URI of the object. In the URI it contains : Resource + object
> identifier.
>
> So when you will try to load that objects from its URI.. it will go the
> resourset.. and load it from there.
> You will have register your resource in the resourset. SO the specific
> resource could be assocaite with any CDOTransaction.
>
Currently in CDO there is a 1:1 association between resource set and
transaction. Would you like to change that?

>> But even more important your scenario always predicts that all clients go
>> through the same set of repositories as members of the XA. Would you vote
>> for denying access to a single repository only because it was used in a XA
>> commit?
>>
> I don't understand your question. Can you clarify your thoughts ? I will try
> to answer.. but not sure if it will answer your question.
> XA point of view is .. It doesn't matter if objects are from the same repo
> or different repo. It should always work.... in both cases.
> My scenario predicts that I will go the repositories that was register in
> the resourceset. At this point it doesn't know if it is a XA transaction.
> We will add XA to ensure the integrity of the graph.
>
I'll try to say it with an example (given we had inter-repo refs):

- Client 1 uses a distributed transaction to commit into 2 repositories
repoA and repoB. An inter-repo ref [R] from repoA -> repoB is part of
the transaction.
- Some time later client 2 uses a normal transaction/view to navigate
the object graph of repoA. When it tries to dereference [R] it comes to
an InconsistentObjectGraphException.

>
>> Regards,
>> Eike Stepper
>> ----
>> http://wiki.eclipse.org/CDO
>> http://wiki.eclipse.org/Net4j
>>
>>
>>
>> Simon McDuff schrieb:
>>
>>> Aside from the XA discussion what exactly do you mean with "adjust
>>> references"?
>>>
>>> Let say I have objectA(from repoA) and objectB(From repoB)
>>> objectA.setXXX(objectB);
>>> objectB.setXXX(objectA);
>>> Both of them need to know the id of the other objects. Important: id plus
>>> session!
>>>
>>>
>>> They will need to adjust their reference after sending the request. I
>>> still don't know what you mean ;-(
>>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>>> differences places.
>>>
>>> I'd say you were right if it was feasible *and* appropriate.
>>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>>> to discuss the appropriateness if you can proof that it's feasible at
>>> all.
>>>
>>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>>> After that it is easy!!
>>> - You have XA to ensure the integrity of the graph. - Each repos could
>>> save PROXY(URI)
>>> - JPA will do the mapping between them.
>>> - Each resource will be associate with a repo. This mapping will be
>>> done through JPA.
>>> - When you load an object, to resolve it it will go through the
>>> resourceset.. where it will connect automatically to the right CDOSEssion
>>> to get to the data.
>>>
>>> I don't see where it is not feasible.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>

--------------090200080707080506080505
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">
Simon McDuff schrieb:
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<pre wrap="">"Eike Stepper" <a class="moz-txt-link-rfc2396E" href="mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</a> wrote in message
<a class="moz-txt-link-freetext" href="news:fk8ses$vt0$4@build.eclipse.org">news:fk8ses$vt0$4@build.eclipse.org</a>...
</pre>
<blockquote type="cite">
<pre wrap="">Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for the
proxy that an arbitrary client can reconsrtuct that right session?
</pre>
</blockquote>
<pre wrap=""><!---->I will use URI of the object. In the URI it contains : Resource + object
identifier.

So when you will try to load that objects from its URI.. it will go the
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific
resource could be assocaite with any CDOTransaction.
</pre>
</blockquote>
Currently in CDO there is a 1:1 association between resource set and
transaction. Would you like to change that?<br>
<br>
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<blockquote type="cite">
<pre wrap="">But even more important your scenario always predicts that all clients go
through the same set of repositories as members of the XA. Would you vote
for denying access to a single repository only because it was used in a XA
commit?
</pre>
</blockquote>
<pre wrap=""><!---->I don't understand your question. Can you clarify your thoughts ? I will try
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same repo
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register in
the resourceset. At this point it doesn't know if it is a XA transaction.
We will add XA to ensure the integrity of the graph.
</pre>
</blockquote>
I'll try to say it with an example (given we had inter-repo refs):<br>
<br>
- Client 1 uses a distributed transaction to commit into 2 repositories
repoA and repoB. An inter-repo ref [R] from repoA -&gt; repoB is part
of the transaction.<br>
- Some time later client 2 uses a normal transaction/view to navigate
the object graph of repoA. When it tries to dereference [R] it comes to
an InconsistentObjectGraphException.<br>
<br>
<blockquote cite="mid:fk8tdn$h23$1@build.eclipse.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Regards,
Eike Stepper
----
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</a>
<a class="moz-txt-link-freetext" href="http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</a>



Simon McDuff schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">Aside from the XA discussion what exactly do you mean with "adjust
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id plus
session!


They will need to adjust their reference after sending the request. I
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate
to discuss the appropriateness if you can proof that it's feasible at
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will be
done through JPA.
- When you load an object, to resolve it it will go through the
resourceset.. where it will connect automatically to the right CDOSEssion
to get to the data.

I don't see where it is not feasible.







</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->

</pre>
</blockquote>
</body>
</html>

--------------090200080707080506080505--


Re: [cdo][0.8.0] [message #612892 is a reply to message #104935] Tue, 18 December 2007 19:42 Go to previous message
Simon Mc Duff is currently offline Simon Mc DuffFriend
Messages: 596
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.

------=_NextPart_000_0112_01C84184.3FE59C40
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable


"Eike Stepper" <stepper@sympedia.de> wrote in message =
news:fk91k7$g26$1@build.eclipse.org...
Simon McDuff schrieb:=20
"Eike Stepper" <stepper@sympedia.de> wrote in message=20
news:fk8ses$vt0$4@build.eclipse.org...
Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect=20
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for =
the=20
proxy that an arbitrary client can reconsrtuct that right session?
I will use URI of the object. In the URI it contains : Resource + =
object=20
identifier.

So when you will try to load that objects from its URI.. it will go the=20
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific=20
resource could be assocaite with any CDOTransaction.
Currently in CDO there is a 1:1 association between resource set and =
transaction. Would you like to change that?
Yes, It would be more a resource attach to a transaction. DO you see =
any problems ?


But even more important your scenario always predicts that all clients =
go=20
through the same set of repositories as members of the XA. Would you =
vote=20
for denying access to a single repository only because it was used in a =
XA=20
commit?
I don't understand your question. Can you clarify your thoughts ? I =
will try=20
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same =
repo=20
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register =
in=20
the resourceset. At this point it doesn't know if it is a XA =
transaction.
We will add XA to ensure the integrity of the graph.
I'll try to say it with an example (given we had inter-repo refs):

- Client 1 uses a distributed transaction to commit into 2 =
repositories repoA and repoB. An inter-repo ref [R] from repoA -> repoB =
is part of the transaction.
- Some time later client 2 uses a normal transaction/view to navigate =
the object graph of repoA. When it tries to dereference [R] it comes to =
an InconsistentObjectGraphException.

Yes we had no choice.
It should react exactly the same way as we were doing crossreference =
between resources in EMF.. The resource XXX isn't reachable..=20
Right ?



Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j



Simon McDuff schrieb:
Aside from the XA discussion what exactly do you mean with "adjust=20
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id =
plus=20
session!


They will need to adjust their reference after sending the request. I=20
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two=20
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate =

to discuss the appropriateness if you can proof that it's feasible at=20
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could=20
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will =
be=20
done through JPA.
- When you load an object, to resolve it it will go through the=20
resourceset.. where it will connect automatically to the right =
CDOSEssion=20
to get to the data.

I don't see where it is not feasible.







=20


------=_NextPart_000_0112_01C84184.3FE59C40
Content-Type: text/html;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-15>
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Eike Stepper" &lt;<A=20
href=3D"mailto:stepper@sympedia.de">stepper@sympedia.de</A>&gt; wrote =
in message=20
<A=20
=
href=3D"news:fk91k7$g26$1@build.eclipse.org">news:fk91k7$g26$1@build.ecli=
pse.org</A>...</DIV>Simon=20
McDuff schrieb:=20
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D"">"Eike Stepper" <A =
class=3Dmoz-txt-link-rfc2396E =
href=3D"mailto:stepper@sympedia.de">&lt;stepper@sympedia.de&gt;</A> =
wrote in message=20
<A class=3Dmoz-txt-link-freetext =
href=3D"news:fk8ses$vt0$4@build.eclipse.org">news:fk8ses$vt0$4@build.ecli=
pse.org</A>...
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Simon,

I think my main point is another one:
It relates a bit to the last sentence of you "where it will connect=20
automatically to the right CDOSEssion".
Can you please explain how you plan to persist enough information for =
the=20
proxy that an arbitrary client can reconsrtuct that right session?
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->I will use URI of the =
object. In the URI it contains : Resource + object=20
identifier.

So when you will try to load that objects from its URI.. it will go the=20
resourset.. and load it from there.
You will have register your resource in the resourset. SO the specific=20
resource could be assocaite with any CDOTransaction.
</PRE></BLOCKQUOTE>
<DIV>Currently in CDO there is a 1:1 association between resource set =
and=20
transaction. Would you like to change that?</DIV>
<DIV>Yes, It would be more a resource attach to a transaction. DO you =
see any=20
problems ?<BR><BR></DIV>
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org type=3D"cite">
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">But even more important =
your scenario always predicts that all clients go=20
through the same set of repositories as members of the XA. Would you =
vote=20
for denying access to a single repository only because it was used in a =
XA=20
commit?
</PRE></BLOCKQUOTE><PRE wrap=3D""><!---->I don't understand your =
question. Can you clarify your thoughts ? I will try=20
to answer.. but not sure if it will answer your question.
XA point of view is .. It doesn't matter if objects are from the same =
repo=20
or different repo. It should always work.... in both cases.
My scenario predicts that I will go the repositories that was register =
in=20
the resourceset. At this point it doesn't know if it is a XA =
transaction.
We will add XA to ensure the integrity of the graph.
</PRE></BLOCKQUOTE>
<DIV>I'll try to say it with an example (given we had inter-repo=20
refs):<BR><BR>- Client 1 uses a distributed transaction to commit into =
2=20
repositories repoA and repoB. An inter-repo ref [R] from repoA -&gt; =
repoB is=20
part of the transaction.<BR>- Some time later client 2 uses a normal=20
transaction/view to navigate the object graph of repoA. When it tries =
to=20
dereference [R] it comes to an InconsistentObjectGraphException.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yes we had no choice.<FONT face=3DArial size=3D2></FONT></DIV>
<DIV>It should react exactly the same way as we were doing =
crossreference=20
between resources in EMF.. The resource XXX isn't reachable.. </DIV>
<DIV>Right ?</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT><BR>&nbsp;</DIV>
<BLOCKQUOTE cite=3Dmid:fk8tdn$h23$1@build.eclipse.org =
type=3D"cite"><PRE wrap=3D""> </PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Regards,
Eike Stepper
----
<A class=3Dmoz-txt-link-freetext =
href=3D"http://wiki.eclipse.org/CDO">http://wiki.eclipse.org/CDO</A>
<A class=3Dmoz-txt-link-freetext =
href=3D"http://wiki.eclipse.org/Net4j">http://wiki.eclipse.org/Net4j</A>



Simon McDuff schrieb:
</PRE>
<BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">Aside from the XA =
discussion what exactly do you mean with "adjust=20
references"?

Let say I have objectA(from repoA) and objectB(From repoB)
objectA.setXXX(objectB);
objectB.setXXX(objectA);
Both of them need to know the id of the other objects. Important: id =
plus=20
session!


They will need to adjust their reference after sending the request. I=20
still don't know what you mean ;-(
[SIMON]Both repo aren't necessarly in the same server. Could be at two=20
differences places.

I'd say you were right if it was feasible *and* appropriate.
Up to now I argued that it's not feasible (see above) but I'd appreciate =

to discuss the appropriateness if you can proof that it's feasible at=20
all.

Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
After that it is easy!!
- You have XA to ensure the integrity of the graph. - Each repos could=20
save PROXY(URI)
- JPA will do the mapping between them.
- Each resource will be associate with a repo. This mapping will =
be=20
done through JPA.
- When you load an object, to resolve it it will go through the=20
resourceset.. where it will connect automatically to the right =
CDOSEssion=20
to get to the data.

I don't see where it is not feasible.







</PRE></BLOCKQUOTE></BLOCKQUOTE><PRE wrap=3D""><!---->

</PRE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0112_01C84184.3FE59C40--
Re: [cdo][0.8.0] [message #612895 is a reply to message #104942] Wed, 19 December 2007 05:27 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010007090709010508090108
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Simon McDuff schrieb:
>
>
> "Eike Stepper" <stepper@sympedia.de <mailto:stepper@sympedia.de>>
> wrote in message news:fk91k7$g26$1@build.eclipse.org...
> Simon McDuff schrieb:
>> "Eike Stepper" <stepper@sympedia.de> wrote in message
>> news:fk8ses$vt0$4@build.eclipse.org...
>>
>>> Simon,
>>>
>>> I think my main point is another one:
>>> It relates a bit to the last sentence of you "where it will connect
>>> automatically to the right CDOSEssion".
>>> Can you please explain how you plan to persist enough information for the
>>> proxy that an arbitrary client can reconsrtuct that right session?
>>>
>> I will use URI of the object. In the URI it contains : Resource + object
>> identifier.
>>
>> So when you will try to load that objects from its URI.. it will go the
>> resourset.. and load it from there.
>> You will have register your resource in the resourset. SO the specific
>> resource could be assocaite with any CDOTransaction.
>>
> Currently in CDO there is a 1:1 association between resource set
> and transaction. Would you like to change that?
> Yes, It would be more a resource attach to a transaction. DO you
> see any problems ?
>
I do see a lot of technical issues although.that alone doesn't prevent
from an eventual solution ;-)
I do see a major shift of paradigm as well.

You know that I'm generally not against technical challenges and
interesting new features but I still believe that this undertaking would
have a major impact on the existing concepts and solutions. This has at
least two consequences for me (and you):

1) Before digging into code of an eventual patch (or even creating such
a patch) I'd rather like to see something like a feasibility studie with
a detailed spec of the problem, a detailed spec of the suggested
solution and a detailed impact analysis. I know that thos would much
easier if there was a detailed spec of the current solution. But your
previous feature requests (btw. with cool results!) and the expectable
issues with the large code base could be blamed for the minor progress
I'm achieving with the documentation ;-) May be this is the point where
I'm finally pushed to write a detailed technical spec of the whole CDO
system...

2) This change could not be published as a normal I-build. It would
force the creation of a new branch. Absolutely doable but a lot of
effort, too. If you want to start prototyping I strongly recommend that
you do that in a separate workspace (your local branch).

>
>>> But even more important your scenario always predicts that all clients go
>>> through the same set of repositories as members of the XA. Would you vote
>>> for denying access to a single repository only because it was used in a XA
>>> commit?
>>>
>> I don't understand your question. Can you clarify your thoughts ? I will try
>> to answer.. but not sure if it will answer your question.
>> XA point of view is .. It doesn't matter if objects are from the same repo
>> or different repo. It should always work.... in both cases.
>> My scenario predicts that I will go the repositories that was register in
>> the resourceset. At this point it doesn't know if it is a XA transaction.
>> We will add XA to ensure the integrity of the graph.
>>
> I'll try to say it with an example (given we had inter-repo refs):
>
> - Client 1 uses a distributed transaction to commit into 2
> repositories repoA and repoB. An inter-repo ref [R] from repoA ->
> repoB is part of the transaction.
> - Some time later client 2 uses a normal transaction/view to
> navigate the object graph of repoA. When it tries to dereference
> [R] it comes to an InconsistentObjectGraphException.
>
> Yes we had no choice.
> It should react exactly the same way as we were doing
> crossreference between resources in EMF.. The resource XXX isn't
> reachable..
> Right ?
>
No, this is clearly not according to the current requirements (settled
years ago and stabilized through lots of experience with CDO). But
before we start to disput on selected technical details I'd really
suggest that we (mainly you) start to describe the whole solution.

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j





>
>
>
>>
>>> Regards,
>>> Eike Stepper
>>> ----
>>> http://wiki.eclipse.org/CDO
>>> http://wiki.eclipse.org/Net4j
>>>
>>>
>>>
>>> Simon McDuff schrieb:
>>>
>>>> Aside from the XA discussion what exactly do you mean with "adjust
>>>> references"?
>>>>
>>>> Let say I have objectA(from repoA) and objectB(From repoB)
>>>> objectA.setXXX(objectB);
>>>> objectB.setXXX(objectA);
>>>> Both of them need to know the id of the other objects. Important: id plus
>>>> session!
>>>>
>>>>
>>>> They will need to adjust their reference after sending the request. I
>>>> still don't know what you mean ;-(
>>>> [SIMON]Both repo aren't necessarly in the same server. Could be at two
>>>> differences places.
>>>>
>>>> I'd say you were right if it was feasible *and* appropriate.
>>>> Up to now I argued that it's not feasible (see above) but I'd appreciate
>>>> to discuss the appropriateness if you can proof that it's feasible at
>>>> all.
>>>>
>>>> Repos will only need to be able to save PROXY.(CDOIDTypeImpl).
>>>> After that it is easy!!
>>>> - You have XA to ensure the integrity of the graph. - Each repos could
>>>> save PROXY(URI)
>>>> - JPA will do the mapping between them.
>>>> - Each resource will be associate with a repo. This mapping will be
>>>> done through JPA.
>>>> - When you load an object, to resolve it it will go through the
>>>> resourceset.. where it will connect automatically to the right CDOSEssion
>>>> to get to the data.
>>>>
>>>> I don't see where it is not feasible.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>

--------------010007090709010508090108
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

<!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">
Simon McDuff schrieb:
<blockquote cite="mid:fk97rm$9qv$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type"
content="text/html;charset=ISO-8859-15">
<meta content="MSHTML 6.00.2900.3199" name="GENERATOR">
<style></style>
<div>


Re: [cdo][0.8.0] [message #612896 is a reply to message #104942] Wed, 19 December 2007 05:42 Go to previous message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Simon,

Without giving any guarantee on how much time I can spend on this issue
I've file two separate enhancements requests and cc'ed you:

Support inter-repository references:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213402

Support distributed transactions:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=213403

Both are P5 to reflect that I currently prefer to work on things like
the exception handling that you proposed ;-)

Regards,
Eike Stepper
----
http://wiki.eclipse.org/CDO
http://wiki.eclipse.org/Net4j


Previous Topic:[CDO][0.8.0] Exception Handling
Next Topic:[CDO][0.8.0] Exception Handling
Goto Forum:
  


Current Time: Thu Mar 28 17:20:24 GMT 2024

Powered by FUDForum. Page generated in 0.07081 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top