[CDO] Best way to manage Detached object/Stale References [message #1800350] |
Tue, 25 December 2018 15:24 |
Alain Picard Messages: 266 Registered: July 2009 |
Senior Member |
|
|
Trying to figure out the best way to manage and deal with detached objects. Having deployed our own store (supporting HgDB) and used CDO for over 10 years, I feel ackward, but here we are converting an app from EMFStore to CDO. This app is pretty dynamic in nature and has a number of deletes, which are resulting in detached objects. We are using both branching and auditing here.
I understand how to identify stale objects at the client and how to clean stale references (we have processes to do that already), but AFAIK that doesn't preclude having to deal with detached/stale (we use proxy policy, just filed issue 543040). I could always return null instead of a detached revision from the store, but I feel that this would have some unintended consequences and see no easy way to condition this behavior. I looked at CDOObjectImpl#dynamicGet, but I can't seem to be able to return an EStoreEList that doesn't contain the stale reference and returning a BasicInternalEList would not provide the correct implementation, unless the get is purely a static read. At the same time I really can't imagine having to filter all get to check for stale references, which would be thousands of places.
What is the expected usage pattern. In an old post it said "the proxy only supports the most fundamental EObject functionality, in particular object identity so that higher level frameworks have a chance to remove/unset the stale reference without risking to run into unexpected/unchecked exceptions.", which seems to imply a usage pattern to clean those references, but what is the optimal time to do so? Any good example (not of how to clean, but when and under which conditions).
Thanks
Alain
|
|
|
Re: [CDO] Best way to manage Detached object/Stale References [message #1800855 is a reply to message #1800350] |
Wed, 09 January 2019 07:35 |
|
Hi Alain,
Over time we've added support for more EObject methods in CDOStaleReferencePolicy.DynamicProxy.processStaleReference(), but I guess you prefer to just not see those proxied elements. Unfortunately that's very hard to achieve. A few thoughts:
- An interesting method is CDOStoreImpl.convertIDToObject(). You can see that it only calls processStaleReference() if no object is found for the given ID. Filtering the entire stale reference out on-the-fly has an impact on the indexes of the following list elements. This impact would need to be remembered somehow, but I don't think we have the required infrastructure/hooks. Perhaps you want to play with the idea and propose a patch to implement the required infrastructure.
- On-the-fly filters would probably only work in (read-only) views.
- In transactions it might be better to actually remove the stale reference from the underlying revision and make the EObject dirty. The next commit could clean up the remote data of that reference.
Sorry that I can't come up with a complete solution.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.07521 seconds