Yeah, it'd definitely be nice to formalize the cache pluggability a bunch. We haven't done it largely because it's really really hard to get pluggability APIs right for just one use case, so in the absence of doing a bunch of plugins, you're unlikely to get it right.
To what extent is the code that you've written something that could be incorporated into OpenJPA as a more-pluggable infrastructure for caching? As I mentioned in a different thread, the lack of license-unencumbered Coherence jars to link against is an issue for pulling in all the code you've worked on, but it sounds like what you've done might be well-abstracted anyhow. The other thing that's always bothered me about OpenJPA's cache pluggability story is that you've gotta duplicate work for the query cache and the data cache -- this seems unnecessary. -Patrick On Fri, Apr 4, 2008 at 5:25 PM, <[EMAIL PROTECTED]> wrote: > alleluia > > I am running Coherence clusters. OpenJPA needs to do the right thing when > it comes to interacting with a cache. Otherwise the all performance aspect > goes by the window. Which is our reason to use a cache in the first place. > > One small suggestion about OpenJPA and caching in general. I think it would > be easier if OpenJPA the O/R Mapping tool and the cache implementation code > was separated. Create an new OpenCache open source project and put the code > in there. > The reason I say this is becuase OpenJPA is quite coupled with its own > cache implementation at the moment. I would be quite happy to go in more > detail on that one if people are interested. Sepratating the two project > might force the dev to create simpler interfaces. > > Seprate the DataCache interface into two - one with the commit method > (required for OpenJPA to access the cache) - and create another interface > with whatever method you want in there for your cache product. > In fact OpenJPA should only need the commit method to a cache facade > (interface) to do its works properly. > All the other methods in DataCache should not be needed by OpenJPA the O/R > mapping tool. > > Just a thought... > > > Frederic > > > > > > "Daniel Lee" > <[EMAIL PROTECTED] > l.com> To > dev@openjpa.apache.org > cc > 04/04/2008 03:08 > > PM Subject > Re: [jira] Created: (OPENJPA-556) > Data cache infrastructure should > Please respond to take advantage of batching > [EMAIL PROTECTED] > e.org > > > > > > > > > > > It is still a good practice because, for the third party data cache plugins > which support special getAll() API to batch the get function may benefit a > lot from the implementation, especially in the cluster environment. > > On Fri, Apr 4, 2008 at 2:18 PM, Patrick Linskey <[EMAIL PROTECTED]> wrote: > > > 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 > > > > > -- Patrick Linskey 202 669 5907
