Community
Participate
Working Groups
Build Identifier: 4.0.1.v20110818 See http://www.eclipse.org/forums/index.php/mv/msg/282461/787330/#msg_787330 >> - For each entry, the SQL Engine does the following: [...] >> SELECT cdo_class FROM cdo_objects WHERE cdo_id=16497 > That's to find out in what table to look up the object identified by the > given ID. The only ways to avoid this are: > > a) Keep *all* object->type mappings in memory. Not feasible for large > models. There is a cache for the object (cdoid) to type (eclass) mapping. What could be done is adding a way to pre-populate the cache (-> please file a bug/enhancement request for that). But a cache is always limited to a certain number of objects, as Eike pointed out. Reproducible: Always Steps to Reproduce: 1. Activate the SQL log 2. Load a large collection of CDOObject => Each item generate the following SQL query: SELECT cdo_class FROM cdo_objects WHERE cdo_id=16497
I'm not very happy about this request because I'm not convinced that the effort needed is justified by the potential benefit. Someone should first make the requirements clearer.
Well, my idea fpr this was to give a server option in the XML file in which you can specify some kind of query to specify objects with which to populate the object type cache. For example: I know that in my application Customers are my top objects which I access all the time. So I configure the server to pre-populate the object-type cache with all objects with EClass Customer. On startup of the server this query is executed and the object IDs are read into the server cache. Of course, this only improves startup time, as the cache will adjust automatically with the LRU strategy. Also, it is the responsibility of the user to adjust the query and the cache size to his own application/domain/model etc.
(In reply to comment #2) I still think that a separate strong reference collection to hold on the frequently used revisions would be the way to go.
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Use cases and requirements are still unclear. Effort would be high. No activity on the bug. Closing as wontfix.
