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
>
