| [CDO] Best way to manage Detached object/Stale References [message #1800350] |
Tue, 25 December 2018 10:24  |
Eclipse User |
|
|
|
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
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.12146 seconds
Home