| [CDO] - exportChanges and detached Objects [message #908986] |
Thu, 06 September 2012 11:02  |
 Missing name Mising name
Messages: 14
Registered: May 2012 |
Junior Member |
|
|
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 11:08] Report message to a moderator |
|
|
|
| Re: [CDO] - exportChanges and detached Objects [message #909491 is a reply to message #908995] |
Fri, 07 September 2012 08:30  |
Missing name Mising name
Messages: 14
Registered: May 2012 |
Junior Member |
|
|
> 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 06:53] Report message to a moderator |
|
|
| Re: [CDO] - exportChanges and detached Objects [message #909498 is a reply to message #909491] |
Fri, 07 September 2012 08:40 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
| Re: [CDO] - exportChanges and detached Objects [message #912299 is a reply to message #912279] |
Thu, 13 September 2012 09:36 |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Powered by
FUDForum. Page generated in 0.04713 seconds
] 
Search
Help
Register
Login
Home
