Alright,
Over the weekend I started to look at what it would take me to change the
behavior of openjpa to make it do what I need as it relates to the L2
Cache.
I started to write a new implementation for that small layer but in order
to finish this work I need to understand openjpa better. Otherwise I am
writting code without knowing how the design works - which would give a
terrible result I am sure ;).
So please help me. In fact please help me help you.
Once the code is written I could send it your way so we will all benefit
from it.
I've written a few questions in this email that I need answer to so I can
finsih the work. It is a bit long email so please if you know anyhting
about openjpa and L2 caching then read on and please respond. Otherwise no
need to read further.
Thank you very much,
Important Reminder - I am not trying to implement an L2 cache at all - I
just want to interface with other L2 cache product. My target right now is
Tangosol but it should not really matter for this conversation. I am making
this clear because some of my questions are related to the fact that the
openjpa code I looked at to add an L2 cache plug-in seems to imply that I
am implementing my own cache mechanism.
First let me say thank you to Pinaki for helping me get started.
The interface for L2 cache is org.apache.openjpa.datacache.DataCache
So I looked into it and understand it - (good sign) but I have a few
questions:
- Do I really need to initialize it? It seems that I dont need this but
please let me know if I am suppose to do something important in here.
- why the writeLock and writeUnlock? Am I suppose to lock the full cache
map in there? It seems that it is so but just want to be sure.
- But then why not the writeLock(object) and unlock(object)? This methods
are part of L2 cache product and obviously are more useful than locking the
full cache?
- OpenJPA is suppose to use optimistic Tx by default - so why should I lock
the cache anyhow?
- addExpirationListener() and removeExpirationListener(): I do not
understand this. If I implement my own cache then I guess I need this. But
an L2 cache product already provides expiration (timeout) of object. So
what is this for really?
- Is the DataCache implementation suppose to be some kind of a proxy to the
real cache? In which case I would need to be notified of certain events -
like expiration.
- The rest of the interface is clear.
But the real code change I have to make seems to actually be somewhere
else.
I found 2 property that seem quite interesting for this work:
<property name="openjpa.DataCache" value="acme.org.MyL2DataCache"/>
I also found <property name="openjpa.DataCacheManager" value=
"com.cccc.MyL2DataCacheManagerImpl"/>
- If I set the openjpa.DataCacheManager property - will it instanciate my
own cache manager?
- If so then why would I need to set the property openjpa.DataCache since
the cache manager is the own creating the DataCache instances?
- Do I need the property openjpa.DataCache only if I dont chnage the
DataCacheManager?
I looked into that DataCacheManager class and it actually seem to be my
starting point. The current implementation has only one cache and it
ignores the name value - and this is the beginning of the problem. So I
already rewrote that class.
- will this property instanciate my new implementation?
- the one million dollar question: Will openjpa call my implementation
getDataCache() method with the proper cache name defined by the @DataCache
annotation of the entity?
- Assuming openjpa does call the DataCacheManager.getDataCache(name) and
passes the name properly - then am I guarrantee that openjpa will always
make the right call to get the right cache whenever it works on a different
entities? By that I mean - if I have entity A in cache a and entity B in
cache b - and If A contains many B - then when I save A with
cascade.persist = true - then I need to be sure that openjpa will call
DataCacheManager.getDataCache(a) to put A in cache a, and then call
DataCacheManager.getDataCache(b) to putAll(Bs) in cache b?
- This is a critical part of course - so I am hopping very hard that
openjpa will behave that way.
In the unfortunate event that openjpa would not call the cache manager to
get the proper cache whenever required then I suppose an alternative would
be to reimplement the call to DataCache.commit(Collection additions,
Collection newUpdates, Collection existingUpdates, Collection deletes).
In which case I would have to let the cache manager pretend there is only
one cache - and in the DataCache class I would need to dispatch all the
calls to the right cache.
But for this to work I need access to the entity type and in particular the
entity DataCache name for all entities that the commit method deals with.
This method takes DataCachePCData and ObjectIDs.
- How do I get the data cache name from the DataCachePCData instances?
- How do I get the data cache name from the objectIds passed?
Thank you for your help in advance,
Frederic
Pinaki Poddar
<[EMAIL PROTECTED]
rg> To
[email protected]
cc
03/28/2008 01:43
PM Subject
Re: How to set a tangosol cache per
entity?
Please respond to
[EMAIL PROTECTED]
che.org
> What interface should I implement?
The interface for L2 cache is org.apache.openjpa.datacache.DataCache.
> How can I tell openjpa to use my implementation?
In META-INF/persistence.xml
<property name="openjpa.DataCache" value="acme.org.MyL2DataCache"/>
> Which class has an implementation of that interface so I can use that as
> an example?
The basic abstract implementation is available in
org.apache.openjpa.datacache.AbstractDataCache.
> Is this plugin managed by openjpa? By that I mean - I am guarranted that
> the plugin will be called at the appropriate time by openjpa and
therefore
> all I would need to worry about is making the call to the cache?
Yes.
Access to OpenJPA internal information is available through
org.apache.openjpa.conf.OpenJPAConfiguration instance. When your
implementation implements org.apache.openjpa.lib.conf.Configurable (which
AbstractDataCache does) -- you have access to OpenJPAConfiguration in right
points of initialization life-cyle. Once you have access to configuration,
you can navigate to OpenJPAConfiguration.getMetaDataRepositoryInstance()
which will tell whatever you want to know of the class level
meta-information.
--
View this message in context:
http://www.nabble.com/How-to-set-a-tangosol-cache-per-entity--tp16336199p16361757.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
