db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg von Frantzius <joerg.von.frantz...@artnology.com>
Subject Re: Cache invalidation
Date Mon, 06 Feb 2006 21:47:57 GMT
Craig L Russell schrieb:
> Hi Jörg,
> Is this issue dead now?
Thanks for asking, no, it's not dead, at least not from my part! I head 
been waiting for another answer from Wes.

I still think that methods DataStoreCache.invalidateByIdXX() similar to 
the evict methods would be very useful. These would discard any cached 
state both from the L2-cache as well as from connected L1-caches. They'd 
/not/ /evict /any objects from L1-caches: issuing a PM.getObjectById() 
before and after DataStoreCache.invalidateById(id) should yield the same 
(==) PC instance (same by object reference). Discarding the state of 
P-nontrans PC instances in L1-caches probably is best achieved by 
transitioning them to hollow state. Also, for any transaction active at 
the time of calling invalidateById(), any affected T-clean or T-dirty 
instance should also transition to hollow when the transaciton finishes 
(probably needs to be more detailed here).

I also think that the evict() methods on DataStoreCache should be 
renamed to evictById(), in order to avoid any confusion with the 
parameter semantics of the PM.evict() methods that have identical method 
signatures. But that's an entirely different issue.
> I looked at the javadoc for these methods and they all refer to oid 
> not pc.
> Thanks,
> Craig
> On Feb 3, 2006, at 1:59 AM, Joerg von Frantzius wrote:
>> Hello JDO developers,
>> in our system we have several VMs that operate on the same database 
>> via JDO. We're performing distributed cache invalidation via our own 
>> notification mechanism, which effectively calls 
>> PMF.getDatastoreCache().evict() and PM.evict(). The problem here is 
>> that either evict() accepts only PC objects, not object ids, so we 
>> have to call PM.getObjectById() beforehand. If no object for that id 
>> was present, we're instantiating a hollow object here only to discard 
>> it afterwards, that's not very effective.
>> As we really want cache invalidation here, not eviction, this is even 
>> worse. For this purpose, it would be far more convenient to have some 
>> method like invalidateCachesFor(Object id) on 
>> PersistenceManagerFactory. To make our wish complete ;) this method 
>> would transition all non-transactional instances to hollow for that 
>> id, for all the PMs the PMF has given out. All transactional objects 
>> with that id should be transitioned to hollow after their transaction 
>> has completed (either with commit or rollback).
>> Or is there some other way to achieve the same effect?
>> Thanks for any comments,
>> Jörg
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!

Dipl.-Inf. Jörg von Frantzius  |            artnology GmbH
                               |                Milastr. 4
Tel +49 (0)30 4435 099 26      |              10437 Berlin
Fax +49 (0)30 4435 099 99      |  http://www.artnology.com

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message