|
|
|
|
| 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   |
|
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.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04366 seconds
] 
Search
Help
Register
Login
Home
