Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] CDOStaleReferencePolicy.PROXY vs bind method(bind an object in audit view to a current transaction throws an exception with proxy policy)
[CDO] CDOStaleReferencePolicy.PROXY vs bind method [message #989205] Wed, 05 December 2012 03:50 Go to next message
Paco Blanco is currently offline Paco Blanco
Messages: 28
Registered: June 2012
Junior Member
We set stale reference policy of an transaction to PROXY mode:
cdoTransaction.options().setStaleReferencePolicy(CDOStaleReferencePolicy.PROXY)


We have an existent (not stale) object in an audit view and want to bind this object to a transaction in PROXY mode. Unluckly, bind method always throws ObjectNotFound exception instead of a proxy object to check CDOUtil.isStaleObject(object).

In fact, this is an possible error to a big unimplement thing:
I have an object in audit view and I do a copy of it that I want to save in db. I bind this new copy object to transaction but at committing all eReference return an "object is from different view" exception. So I have to do a recursive bind of all eReference inner elements and replace them. When I find a stale reference object in the recursive bind, bind methods throws the exception refers in this topic.

[Updated on: Wed, 05 December 2012 03:52]

Report message to a moderator

Re: [CDO] CDOStaleReferencePolicy.PROXY vs bind method [message #989411 is a reply to message #989205] Thu, 06 December 2012 02:03 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Am 05.12.2012 09:50, schrieb Paco Blanco:
> We set stale reference policy of an transaction to PROXY mode:
>
> cdoTransaction.options().setStaleReferencePolicy(CDOStaleReferencePolicy.PROXY)
>
>
> We have an existent (not stale) object in an audit view and want to bind
What is "bind"?

Perhaps you're referring to what we call "contextify" in this CDOView method:

/**
* Takes an object from a (possibly) different view and <em>contextifies</em> it for the usage with this view.
* <ul>
* <li>If the given object is contained in this view it is returned unmodified.
* <li>If the given object can not be cast to {@link CDOObject} it is returned unmodified.
* <li>If the view of the given object is contained in a different session an <code>IllegalArgumentException</code> is
* thrown.
* <li>If <code>null</code> is passed <code>null</code> is returned.
* </ul>
*/
public <T extends EObject> T getObject(T objectFromDifferentView);


> this object to a transaction in PROXY mode. Unluckly, bind method always throws ObjectNotFound exception instead of a
> proxy object to check CDOUtil.isStaleObject(object).
The difference is a little subtle and the confusion may be caused by the term "StaleObject". The underlying concept is a
stale *reference* which always has a declared type even if the target object has been deleted. That's why we can
(optionally) create a Java dynamic proxy for it. CDOUtil.isStaleObject() just tests if that's the case for a given object.

In cases where you try to load an object directly through CDOView.getObject() there is no such persistent reference that
could be stale.

Irrespective of this subtle difference it seems that your object has been deleted between the timestamp of your audit
view and "now". You should catch the ObjectNotFoundException where you CDOView.call getObject().

>
> In fact, this is an possible error to a big unimplement thing:
I'm not sure how to read this statement.

> I have an object in audit view and I do a copy of it that I want to save in db. I bind this new copy object to
> transaction but at committing all eReference return an "object is from different view" exception. So I have to do a
> recursive bind of all eReference inner elements.
Correct.

> When I find a stale reference object in the recursive bind, bind methods throws the exception refers in this topic.
It's not a "stale reference object". It's an object that's not found (because it doesnot exist (anymore?)) where you're
trying to find it.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] CDOStaleReferencePolicy.PROXY vs bind method [message #989944 is a reply to message #989411] Mon, 10 December 2012 02:49 Go to previous messageGo to next message
Paco Blanco is currently offline Paco Blanco
Messages: 28
Registered: June 2012
Junior Member
bind = contextify yes, sorry

So two questions:
- is there some way to check if an object exists in a view (from specified timestamp or transaction at current time)?


- is there some way to restore a deleted Object (to keep the same CDOId)?
Re: [CDO] CDOStaleReferencePolicy.PROXY vs bind method [message #989959 is a reply to message #989944] Mon, 10 December 2012 04:26 Go to previous message
Eike Stepper is currently offline Eike Stepper
Messages: 5486
Registered: July 2009
Senior Member
Am 10.12.2012 08:49, schrieb Paco Blanco:
> bind = contextify yes, sorry
>
> So two questions:
> - is there some way to check if an object exists in a view (from specified timestamp or transaction at current time)?
CDOView.isObjectRegistered(id) tells you whether the object with that ID is currently loaded/cached in that view.
CDOView.getObject(...) throws an ObjectNotFoundException which you can catch to tell whether the object exists remotely.

> - is there some way to restore a deleted Object (to keep the same CDOId)?
AFAIK that's only possible in branching mode when you merge back a deleted object from a branch where it isn't deleted.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Previous Topic:is there a way to manually build xcore instead of automatic build when something changes?
Next Topic:[CDO/Hibernate] UnsupportedOperationException at ...GrowingRandomAccessList.add(...)
Goto Forum:
  


Current Time: Fri Aug 01 04:04:45 EDT 2014

Powered by FUDForum. Page generated in 0.05484 seconds