Eclipse Community Forums: EMF » [CDO] - exportChanges and detached Objects

Home » Modeling » EMF » [CDO] - exportChanges and detached Objects

[CDO] - exportChanges and detached Objects [message #908986]

Thu, 06 September 2012 07:02

Eclipse User

Hi,

why is exportChanges in CDOTransactionImpl ignoring detached objects?
How are deleted objects processed?

By the way, what is the exact meaning of detach in context of CDO? As far as I understand it is often used as synonym for delete.
For me detach means, removing the current object from the context and not deleting it.

Best regards,

Joe

[Updated on: Thu, 06 September 2012 07:08] by Moderator

Re: [CDO] - exportChanges and detached Objects [message #908995 is a reply to message #908986]

Thu, 06 September 2012 07:20

Eclipse User

Am 06.09.2012 13:02, schrieb Joe Sobeos:
> Hi,
>
> why is exportChanges in CDOTransactionImpl ignoring detached objects?
Why do you think they are? From looking at the code or are you experiencing a real problem?

Detachments can always be deduced from the deltas of the containing object.

> How are deleted objects processed?
>
> By the way, what is the exact meaning of detach in context of CDO?
Detach is an EMF term for removing an object from it's container and thereby implicitely from its persistent resource.

> As far as I understand it is often used as synonym for delete.
Yes.

> For me detach means, removing the current object from the context and not deleting it.
They are the same in systems (here EMF) that support and enforce proper containment semantics.

Cheers
/Eike

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

Re: [CDO] - exportChanges and detached Objects [message #909491 is a reply to message #908995]

Fri, 07 September 2012 04:30

Eclipse User

> Why do you think they are? From looking at the code or are you experiencing a real > problem?

Both.
We export changes on the client side and transform them to the server, where they get committed. Objects marked to get deleted were not deleted on the server side.
Looks like they get lost between export and import.
Please have a look to exportChanges in CDOTransactionImpl.
For me detached objects are not handled.

> Detach is an EMF term for removing an object from it's container and thereby
> implicitely from its persistent resource.

Unfortunately google is not delivering too much information about "emf detach".

> They are the same in systems (here EMF) that support and enforce proper
> containment semantics.

Sounds like such systems will get problems with long running transactions (e.g. user think time) and concurrent modifications (other transactions/users).

[Updated on: Thu, 13 September 2012 02:53] by Moderator

Re: [CDO] - exportChanges and detached Objects [message #909498 is a reply to message #909491]

Fri, 07 September 2012 04:40

Eclipse User

Am 07.09.2012 10:30, schrieb Joe Sobeos:
>> Why do you think they are? From looking at the code or are you experiencing a real > problem?
>
> Both.
> We export changes on the client side and transform them to the server, where they get commited. Objects marked to get
> deleted were not deleted on the server side.
> Looks like they get lost between export and import.
> Please have a look to exportChanges in CDOTransactionImpl.
> For me detached objects are not handled.
Then submit a bugzilla please and ideally attach a small test case so that I can reproduce the problem.

>
>> Detach is an EMF term for removing an object from it's container and thereby implicitely from its persistent resource.
>
> Unfortunately google is not delivering too much information about "emf detach".
But now you understand?

>
>> They are the same in systems (here EMF) that support and enforce proper containment semantics.
>
> Sounds like such systems will get problems with long running transactions (e.g. user think time) and concurrent
> modifications (other transactions/users).
Why do you think so?

Cheers
/Eike

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

Re: [CDO] - exportChanges and detached Objects [message #912228 is a reply to message #909498]

Thu, 13 September 2012 03:02

Eclipse User

> Then submit a bugzilla please and ideally attach a small test case so that I can
> reproduce the problem.

Done.
Bug 389473

> Unfortunately google is not delivering too much information about "emf detach".
> But now you understand?

It is not a question of understanding. It is a question of definition and I did not find the emf definition of detach.

> Sounds like such systems will get problems with long running transactions (e.g. user think time) and concurrent
> modifications (other transactions/users).
> Why do you think so?

I have to check the transaction handling of CDO. Is it documented anywhere?
I would expect to get ConcurrentModificationExceptions with long running transactions.

Re: [CDO] - exportChanges and detached Objects [message #912233 is a reply to message #912228]

Thu, 13 September 2012 03:16

Eclipse User

Am 13.09.2012 09:02, schrieb Joe Sobeos:
> [...]
>> Sounds like such systems will get problems with long running transactions (e.g. user think time) and concurrent
>> modifications (other transactions/users).
>> Why do you think so?
>
> I have to check the transaction handling of CDO. Is it documented anywhere?
Not that I know of. What kind of information are you looking for?

> I would expect to get ConcurrentModificationExceptions with long running transactions.
In general yes, but not necessarily. A CDOTransaction receives CommitNotifications from commits of other transactions
which can directly (and early) detect conflicts before even committing. Because of possible network race conditions
there's always (unless you use explicit locking) a "rest" potential for server-side ConcurrentModificationException.

Cheers
/Eike

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

Re: [CDO] - exportChanges and detached Objects [message #912279 is a reply to message #912233]

Thu, 13 September 2012 04:57

Eclipse User

> Not that I know of. What kind of information are you looking for?

Transaction behaviour in general.
-> what happens when two or more transactions modify the same object? A picture
would be nice here.
-> are there any options?

> I would expect to get ConcurrentModificationExceptions with long running
> transactions.
> In general yes, but not necessarily. A CDOTransaction receives CommitNotifications > from commits of other transactions
> which can directly (and early) detect conflicts before even committing. Because of > possible network race conditions
> there's always (unless you use explicit locking) a "rest" potential for server-
> side ConcurrentModificationException.

Is the CDOTransaction handling the ComitNotifications automatically? Or do I have to implement something?

I see two scenarios:
a) I want to get all properties of my object get updated immadiately
b) I don't want to get any property updated at all for a specified object

(How) Does CDO support the two behaviors?

Re: [CDO] - exportChanges and detached Objects [message #912299 is a reply to message #912279]

Thu, 13 September 2012 05:36

Eclipse User

Am 13.09.2012 10:57, schrieb Joe Sobeos:
>> Not that I know of. What kind of information are you looking for?
>
> Transaction behaviour in general.
That's too, eh, general :P

> -> what happens when two or more transactions modify the same object?
They can modify it at the same time if none of them acquired an explicit lock. They can try to commit at the same time
but the server will choose one transaction to succeed first. The other one will fail. If passive updates are enabled it
may happen (depending on the actual timing) that one transaction is notified about the success of the other transaction
and cannot even commit anymore.

> A picture would be nice here.
Maybe, but I don't have time right now to make one ;-(

> -> are there any options?
Have a look at CDOTransaction.options().

>> In general yes, but not necessarily. A CDOTransaction receives CommitNotifications > from commits of other
>> transactions which can directly (and early) detect conflicts before even committing. Because of > possible network
>> race conditions there's always (unless you use explicit locking) a "rest" potential for server-
>> side ConcurrentModificationException.
> I would expect to get ConcurrentModificationExceptions with long running transactions.
>
> Is the CDOTransaction handling the ComitNotifications automatically? Or do I have to implement something?
It handles them automatically. If changes arrive for objects that are locally dirty then an application supplied
CDOConflictResolver has the chance to resolve that conflict. If it cannot then the object transitions to
CDOState.CONFLICT and CDOTransaction.hasConflict() will return true.

> I see two scenarios:
> a) I want to get all properties of my object get updated immadiately
Use CDOSession.options().setPassiveUpdateEnabled(true).

> b) I don't want to get any property updated at all for a specified object
Use CDOSession.options().setPassiveUpdateEnabled(false).

Note that this affects *all* views/transactions of that session.

Cheers
/Eike

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

Previous Topic:	[XCore] derived feature, manual code
Next Topic:	(no subject)

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 20 11:41:05 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter