The latest snapshot should have this behavior now. > It won't gain much for OpanJPA "native" > data cache since it is delegated to AbstractDataCache.getAll() (ln. 449) > which loops thru the list to get the objects from the cache. However, it > save the traffic if any.
Also, the built-in data cache is local-only, with remote invalidations handled via the RemoteCommitProvider. So the difference between a series of get() calls vs. batching is negligible anyways. -Patrick On Fri, Apr 4, 2008 at 1:01 PM, Daniel Lee <[EMAIL PROTECTED]> wrote: > That's right, that the code here (transformToVersionSafePCDatas) should call > cache.containsAll() or cache.getAll(). That way, it will save a lot for any > data cache that provide getAll(). It won't gain much for OpanJPA "native" > data cache since it is delegated to AbstractDataCache.getAll() (ln. 449) > which loops thru the list to get the objects from the cache. However, it > save the traffic if any. > > On Thu, Apr 3, 2008 at 11:51 PM, Patrick Linskey (JIRA) <[EMAIL PROTECTED]> > wrote: > > > > > Data cache infrastructure should take advantage of batching > > ----------------------------------------------------------- > > > > Key: OPENJPA-556 > > URL: https://issues.apache.org/jira/browse/OPENJPA-556 > > Project: OpenJPA > > Issue Type: Improvement > > Reporter: Patrick Linskey > > > > > > From the newsgroup: > > > > "The DataCacheStoreManager.transformToVersionSafePCDatas() line 261. This > > method should call either cache.containsAll() or cache.getAll(). The > > current implementation makes one call to the cache for each element in the > > collection." > > > > -- > > This message is automatically generated by JIRA. > > - > > You can reply to this email to add a comment to the issue online. > > > > > -- Patrick Linskey 202 669 5907
