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:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] email: [EMAIL PROTECTED] GSM: 06.73.16.09.32 MSN: [EMAIL PROTECTED] Try our JDO product: http://speedo.objectweb.org
