[CDO] fully load model object for use outside of transaction [message #1835764] |
Fri, 11 December 2020 19:14  |
Eclipse User |
|
|
|
Hi, I'd like to return CDO model objects from a spring controller to the caller but get a failure during json serialization because serialiization occurs in the spring framework after returning from the controller method and I've closed the CDO transaction by then. Is there a way to fully load a model object such that even after a transaction is closed the fields can be resolved? I'm currently using CDOUtil.getObject(CDOID) to fetch these objects. Should I use getObject(CDOID, loadOnDemand) and with loadOnDemand set to "false" so that it doesn't load on demand and loads everything? Its unclear from the javadoc that I'm looking at what loadOnDemand means in this context. Or does loadOnDemand mean something entirely different?
|
|
|
Re: [CDO] fully load model object for use outside of transaction [message #1835766 is a reply to message #1835764] |
Fri, 11 December 2020 19:58   |
Eclipse User |
|
|
|
Hi
In EMF, load-on-demand determines where loading a Resource from disk is lazy or eager, not whether the Resource contents are resolved eagerly.
For straight EMF, invoking EcoreUtil.resolveAll on the Resource (or ResourceSet) should visit everything and so force resolution without needing to code a custom traversal. CDO may need more / have a better facility.
Regards
Ed Willink
|
|
|
|
Re: [CDO] fully load model object for use outside of transaction [message #1835770 is a reply to message #1835764] |
Fri, 11 December 2020 20:54   |
Eclipse User |
|
|
|
An update to this. I'm actually not using the getCDOObject() method in many cases these are results from CDO queries so a mechanism to resolve an object after its fetched rather than during the fetch would be the simplest to integrate. Although a mechanism to eagerly load the CDO objects during the query would solve the issue too.
|
|
|
Re: [CDO] fully load model object for use outside of transaction [message #1835778 is a reply to message #1835770] |
Sat, 12 December 2020 09:16   |
Eclipse User |
|
|
|
Hi, I think that quite a few topics are mixed into this thread, most of them probably unrelated to the original question/problem. Nevertheless, here are a few facts:
1) CDOObjects can not be used anymore after the view/transaction that loaded them is closed. That's intentional. If you need to use objects outside of the view/transaction you must copy them before it's closed. In theory you could also detach them from their CDOResource(s) without committing that modification, but copying is the preferred alternative (and the only one if the view is read-only).
2) CDOView.getObject(cdoid, loadOnDemand) fetches an object from the view cache of objects. The loadOnDemand parameter specifies what happens if the requested object is not in the cache. If loadOnDemand is false then null is returned. If loadOnDemand is true then the object is loaded from the repository, cached in the view, and returned.
3) References between persistent CDOObjects work fundamentally different from normal EObjects. EMF's resolve/resolveAll are normally not needed in CDO. The latter can cause many sequential server round-trips. CDO's prefetching mechanisms are usually preferred to load multiple objects / trees in one server round-trip.
4) How a CDOQuery behaves is determined by the server-side IQueryHandler that's selected for the query. See org.eclipse.emf.cdo.internal.server.Repository.getQueryHandler(CDOQueryInfo). Without knowing how exactly you create the CDOQuery on the client-side (e.g., language, parameters, ...) I can't tell how it behaves on the server-side. For example the SQLQueryHandler by default returns CDOIDs over the wire. These are eventually turned into CDOObjects (see point 2 above). This results in additional load requests to the server for the objects that are not yet cached. If that leads to poor performance you can get the query results as CDOIDs instead of CDOObjects. Then you can look them up in the local cache with loadOnDemand=false. This leads to two sets, one with the already cached objects and one with the CDOIDs of the missing objects. The missing objects can then be loaded in one server round-trip, see view.getSession().getRevisionManager().getRevisions(List<CDOID>, ...). BTW., it strikes me that I should add a getObjects(Collection<CDOID>) method directly to CDOView that provides this optimization for multiple object lookups.
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04726 seconds