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 Tue, 07 Feb 2006 13:45:18 GMT
Chassande-Barrioz Sébastien schrieb:
> 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.
I assume that you don't want to add methods that'll have the same 
semantics as the existing ones. So if we just add new methods with the 
old semantics, that'll equally break existing code, because the 
semantics of the existing ones should then change from accepting IDs to 
accepting PCs. Only you won't see the broken code as compile errors ;)

So even if we add methods, users need to change their code, and chances 
are they are more likely to do so when they see compile errors...

BTW, that would mean 4 more convenience methods, so we'd end up with 8 
methods for doing nearly the same in DataStoreCache. So far we have: 
evict (Object oid), evictAll (Object[] oids), evictAll (Collection 
oids), evictAll (Class pcClass, boolean subclasses).
>
> 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?
>>     
Are there any left?    ;-)

Just joking. However, I'd think that DataStoreCache.evictXX() calls 
aren't found so often in an application, and it might also be not that 
many applications that use it at all. A little name change to make 
things compile again, and you're done, and the best thing is you can see 
immediately that you need to do it (no change of semantics).
>> 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 <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 <mailto:sebastien.chassandebarrioz@rd.francetelecom.com>
> email: sebastien.chassande-barrioz@laposte.net <mailto:sebastien.chassande-barrioz@laposte.net>
> GSM: 06.73.16.09.32
> MSN: klaneon@yahoo.fr <mailto:klaneon@yahoo.fr>
>
> Try our JDO product: http://speedo.objectweb.org
>         
>


-- 
__________________________________________________________
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
_______________________________|__________________________


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