Skip to main content



      Home
Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc)  » CDO internals
CDO internals [message #125116] Wed, 04 June 2008 04:26 Go to next message
Eclipse UserFriend
Originally posted by: darpan.cmu.edu

Hi,

I am wondering if how CDO internally works could help me solve my problem.
The scenarios is as follows:
I have two identical models M1 and M2 each containing an element A. I
modify M1 by adding element B to A (using GEF) to get A', and now want to
apply the same model change to M2. As soon as I get the notification I try
to look for A in M2 and want to add B to it as well. Unfortunately I cant
find A in M2 because the Notification event contains A' and not A, so
EmfCoreUtil.equals returns false.

I wonder how CDO transfers model changes from one machine to another? I
think in principle I should be able to apply the same technique here.

Any help appreciated.

Thanks,
-darpan
Re: CDO internals [message #125134 is a reply to message #125116] Wed, 04 June 2008 12:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Darpan,

I have the feeling that the CDO way of detecting/transfering/applying
model changes is a bit of an overkill for your scenario, but maybe I got
you wrong.

Nonetheless a few details:
- In CDO each object has an internal, unique OID which is assigned by
the repository, once the obejct got persisted in a transaction.
- The modeled state (attribute+reference values) of the objects is kept
in an EStore.
- The EStore implementation creates object/feature change deltas.
- The change deltas are transfered over the net in a binary form,
thereby using the persistent OIDs to refer to objects.
- The repository passes all the change deltas to a storage backend
implementation to persist the changes.
- The repository emits invalidation notifications to the other sessions.
- The other sessions invalidate the changed objects, so that subsequent
access will trigger new load requests (which currently don't use deltas).

HTH and please come back with more detailed questions if you still think
that it's beneficial for your project ;-)

Cheers
/Eike




Darpan Saini schrieb:
> Hi,
>
> I am wondering if how CDO internally works could help me solve my
> problem. The scenarios is as follows:
> I have two identical models M1 and M2 each containing an element A. I
> modify M1 by adding element B to A (using GEF) to get A', and now want
> to apply the same model change to M2. As soon as I get the
> notification I try to look for A in M2 and want to add B to it as
> well. Unfortunately I cant find A in M2 because the Notification event
> contains A' and not A, so EmfCoreUtil.equals returns false.
>
> I wonder how CDO transfers model changes from one machine to another?
> I think in principle I should be able to apply the same technique here.
>
> Any help appreciated.
>
> Thanks,
> -darpan
>
Re: CDO internals [message #125181 is a reply to message #125134] Fri, 06 June 2008 05:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: darpan.cmu.edu

Hi Eike,

I appreciate your promptness in replying. I will take a look at the EStore
implementation that calculates the deltas. Also, I wonder how you transfer
them in binary format?

The other approach that I have tried is to capture the change command.
Once I know that a particular command has to be executed on a model
element I try to execute the same command on the same model element on
other clients. This approach just came to me a couple of days ago but with
this my primary concern is to serialize just an element of the model so
that it can be identified on the other side. I think assigning an ID
should help. So that I can identify each element based on the id.

Let me know what you think of this.

Thanks,
-darpan
Re: CDO internals [message #125243 is a reply to message #125181] Fri, 06 June 2008 09:40 Go to previous message
Eclipse UserFriend
Originally posted by: stepper.sympedia.de

Hi Darpan,

If you really want to look at my EStore implementation you should start
at
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=markup

For the binary transfer I'm using Net4j which was originally developed
just to serve as a signalling backbone for CDO.

For the other questions it's best to ask directly on the EMF newsgroup ;-)

Cheers
/Eike



Darpan Saini schrieb:
> Hi Eike,
>
> I appreciate your promptness in replying. I will take a look at the
> EStore implementation that calculates the deltas. Also, I wonder how
> you transfer them in binary format?
>
> The other approach that I have tried is to capture the change command.
> Once I know that a particular command has to be executed on a model
> element I try to execute the same command on the same model element on
> other clients. This approach just came to me a couple of days ago but
> with this my primary concern is to serialize just an element of the
> model so that it can be identified on the other side. I think
> assigning an ID should help. So that I can identify each element based
> on the id.
>
> Let me know what you think of this.
>
> Thanks,
> -darpan
>
Re: CDO internals [message #619168 is a reply to message #125116] Wed, 04 June 2008 12:12 Go to previous message
Eclipse UserFriend
Hi Darpan,

I have the feeling that the CDO way of detecting/transfering/applying
model changes is a bit of an overkill for your scenario, but maybe I got
you wrong.

Nonetheless a few details:
- In CDO each object has an internal, unique OID which is assigned by
the repository, once the obejct got persisted in a transaction.
- The modeled state (attribute+reference values) of the objects is kept
in an EStore.
- The EStore implementation creates object/feature change deltas.
- The change deltas are transfered over the net in a binary form,
thereby using the persistent OIDs to refer to objects.
- The repository passes all the change deltas to a storage backend
implementation to persist the changes.
- The repository emits invalidation notifications to the other sessions.
- The other sessions invalidate the changed objects, so that subsequent
access will trigger new load requests (which currently don't use deltas).

HTH and please come back with more detailed questions if you still think
that it's beneficial for your project ;-)

Cheers
/Eike




Darpan Saini schrieb:
> Hi,
>
> I am wondering if how CDO internally works could help me solve my
> problem. The scenarios is as follows:
> I have two identical models M1 and M2 each containing an element A. I
> modify M1 by adding element B to A (using GEF) to get A', and now want
> to apply the same model change to M2. As soon as I get the
> notification I try to look for A in M2 and want to add B to it as
> well. Unfortunately I cant find A in M2 because the Notification event
> contains A' and not A, so EmfCoreUtil.equals returns false.
>
> I wonder how CDO transfers model changes from one machine to another?
> I think in principle I should be able to apply the same technique here.
>
> Any help appreciated.
>
> Thanks,
> -darpan
>
Re: CDO internals [message #619199 is a reply to message #125134] Fri, 06 June 2008 05:37 Go to previous message
Eclipse UserFriend
Originally posted by: darpan.cmu.edu

Hi Eike,

I appreciate your promptness in replying. I will take a look at the EStore
implementation that calculates the deltas. Also, I wonder how you transfer
them in binary format?

The other approach that I have tried is to capture the change command.
Once I know that a particular command has to be executed on a model
element I try to execute the same command on the same model element on
other clients. This approach just came to me a couple of days ago but with
this my primary concern is to serialize just an element of the model so
that it can be identified on the other side. I think assigning an ID
should help. So that I can identify each element based on the id.

Let me know what you think of this.

Thanks,
-darpan
Re: CDO internals [message #619200 is a reply to message #125181] Fri, 06 June 2008 09:40 Go to previous message
Eclipse UserFriend
Hi Darpan,

If you really want to look at my EStore implementation you should start
at
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.emf/org .eclipse.emf.cdo/plugins/org.eclipse.emf.cdo/src/org/eclipse /emf/internal/cdo/CDOStore.java?root=Modeling_Project&vi ew=markup

For the binary transfer I'm using Net4j which was originally developed
just to serve as a signalling backbone for CDO.

For the other questions it's best to ask directly on the EMF newsgroup ;-)

Cheers
/Eike



Darpan Saini schrieb:
> Hi Eike,
>
> I appreciate your promptness in replying. I will take a look at the
> EStore implementation that calculates the deltas. Also, I wonder how
> you transfer them in binary format?
>
> The other approach that I have tried is to capture the change command.
> Once I know that a particular command has to be executed on a model
> element I try to execute the same command on the same model element on
> other clients. This approach just came to me a couple of days ago but
> with this my primary concern is to serialize just an element of the
> model so that it can be identified on the other side. I think
> assigning an ID should help. So that I can identify each element based
> on the id.
>
> Let me know what you think of this.
>
> Thanks,
> -darpan
>
Previous Topic:[Announce] EMF CDO Builds are available
Next Topic:[Teneo] JMX MBean and class loading issues
Goto Forum:
  


Current Time: Sat Jul 19 06:56:57 EDT 2025

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

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

Back to the top