db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chassande-Barrioz Sébastien <sebastien.chassandebarr...@rd.francetelecom.com>
Subject Re: Cache invalidation
Date Tue, 07 Feb 2006 08:10:47 GMT
Hi Craig,

I think we should add new methods instead of renaming. Another solution
could be to support persistent object and identifier in the evict*
methods.

Regards,
Seb

Le lundi 06 février 2006 à 16:00 -0800, Craig L Russell a écrit :

> For the record,
> 
> I'm not opposed to name changes as long as they are consistent and  
> there is time in the release cycle to implement (trivial). I think  
> the proposal is to change all of the names in the DataStoreCache API  
> to include "ById".
> 
> Do we care about any users who would be affected?
> 
> Craig
> 
> On Feb 6, 2006, at 2:53 PM, Wes Biggs wrote:
> 
> > I agree that it would be nice to change the method signatures to  
> > "evictById" for those that take OIDs in order to avoid confusion.
> >
> > To clarify what I mean about persistent nontransactional objects,  
> > see section 5.6.1 of the spec:
> > "A persistent-nontransactional instance transitions to persistent- 
> > clean if any managed field
> > is accessed when a datastore transaction is in progress. The state  
> > of the instance in memory
> > is discarded and the state is loaded from the datastore."
> >
> > If you are running with an optimistic transaction instead, you'll  
> > get an optimistic verification exception at commit time.  So I  
> > guess it is possible to read stale data from the instance in the PM  
> > cache under a couple of scenarios:
> >
> > 1. Reading previously loaded fields of a P-NT instance outside of a  
> > transaction.
> > 2. Reading previously loaded fields of a P-NT instance inside an  
> > optimistic transaction.
> >
> > In these cases, I think you're right that it would be necessary to  
> > hollow the instances in order to be absolutely sure that no stale  
> > data is read after a L2 cache evict().
> >
> > On the other hand, if you're in an optimistic transaction, don't  
> > you want to retain the previously read values (they represent the  
> > ACID guarantee from the optimistic transaction)?  So the only case  
> > where it might make sense to me is #1 above, and that seems  
> > debatable to me.  Do most people using P-NT objects expect them to  
> > be consistent with the L2 cache at all times?  Or are they expected  
> > to act like a limited form of an optimistic transaction?
> >
> > I don't have a strong opinion about this, I'm just trying to fully  
> > articulate the question.
> >
> > Wes
> >
> > Joerg von Frantzius wrote:
> >
> >> Hi Wes,
> >>
> >> thanks for your answer, please see my comments below.
> >>
> >> Wesley Biggs schrieb:
> >>
> >>> Joerg von Frantzius wrote:
> >>>
> >>>> 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.
> >>>
> >>> I'm not quite parsing your "either" here, sorry.  But  
> >>> DataStoreCache.evict() accepts object IDs.  I'm not sure I see  
> >>> the necessity of calling PM.evict() as well, unless you have some  
> >>> particularly long-lived transactions.
> >>
> >> We're doing nontransactional reads on long-living objects, so I  
> >> guessed we needed to call PM.evict() to avoid accessing stale  
> >> field data.
> >>
> >> You're of course right about DatastoreCache.evict() accepting IDs,  
> >> thanks for pointing that out. I had just seen the same method  
> >> signature, and so I assumed the parameter semantics also being the  
> >> same.
> >>
> >> Calling it evictById() probably would be less misleading, even  
> >> more so as a mistake here won't show up immediately. Also, if you  
> >> only have a jar without sourcecode, the signatures are absolutely  
> >> indistinguishable (Which of course is not an excuse for not having  
> >> read the spec thoroughly enough ;)
> >>
> >>>> 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.
> >>>
> >>> That's the intention of DataStoreCache.evict().  The semantics  
> >>> are different than PM.evict().
> >>
> >> Only now I start understanding that I was misled by the word evict 
> >> () for the L2-cache: as the user never gets hold of an L2 cache  
> >> object anyway (a L1-cache object will be created for that), he  
> >> shouldn't need to care whether the L2 cache internally needs to  
> >> throw away (evict) some object in order to invalidate cached  
> >> state. Spec says "/The evict methods are hints to the  
> >> implementation that the instances referred to by the object ids  
> >> are stale and should be evicted from the cache./" It might be nit- 
> >> picking, but I think it would be clearer if the method was called  
> >> invalidateByÍd(), which would be natural for some cache interface,  
> >> and if the explanation said "/that the object state referred to by  
> >> the object ids should be discarded/"
> >>
> >> Also, the spec doesn't say anything about DatastoreCache.evict()  
> >> having any impact on P-nontrans instances. So I still need to go  
> >> to every PM and evict there as well, which is very inconvenient.
> >>
> >> Or does the "evict" row in table 2 for P-nontrans really apply to / 
> >> both /evict() methods, not only PM.evict()!? The RI JPOX isn't  
> >> doing anything like that, by the way.
> >>
> >>>> 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).
> >>>
> >>> Persistent nontransactional instances will have to be revalidated  
> >>> against the datastore (or cache thereof) before being re-enlisted  
> >>> in a transaction anyway.  The behavior you mention is a good way  
> >>> to implement that, but it doesn't need to be mandated (hollow is  
> >>> not a user-visible state).
> >>
> >> I'm not sure what you mean by mandating here? I'd just like to  
> >> make sure that invalidated non-transactional instances will reload  
> >> state upon next read access, without having to iterate all PMs.  
> >> Also, I'd rather not like a call to PM.getObjectById() afterwards  
> >> returning a new Java object for the same id, which I guess is the  
> >> case after calling PM.evict(PM.getObjectById(id)).
> >>
> >> If a method invalidateById() existed, I'd see the sense of evict()  
> >> in releasing the associated memory. evict() currently does two  
> >> things at same time: evicting and transitioning to hollow. For  
> >> (distributed) cache invalidation, I find it sensible to desire  
> >> only the latter.
> >>
> >> Regards,
> >> 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!
> 

-- 
Sebastien Chassande-Barrioz
Research & Development Engineer
France Telecom, Research & Development, MAPS/AMS laboratory
28 chemin du Vieux Chene - B.P. 98
38243 Meylan CEDEX - France
phone: +33.4.76.76.42.10 - fax: +33.4.76.76.45.57
email: sebastien.chassandebarrioz@rd.francetelecom.com
email: sebastien.chassande-barrioz@laposte.net
GSM: 06.73.16.09.32
MSN: klaneon@yahoo.fr

Try our JDO product: http://speedo.objectweb.org

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