Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43E69493.5060404@artnology.com>
Date: Mon, 06 Feb 2006 01:13:07 +0100
From: Joerg von Frantzius <joerg.von.frantzius@artnology.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Apache JDO project <jdo-dev@db.apache.org>
Subject: Re: Cache invalidation
References: <A6153018-AF90-492D-AFE4-6343109472DF@Sun.COM>
 <43E32981.7010807@artnology.com> <43E64533.5060904@tralfamadore.com>
In-Reply-To: <43E64533.5060904@tralfamadore.com>
Content-Type: multipart/alternative;
 boundary="------------070500050907010103050303"

--------------070500050907010103050303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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


--------------070500050907010103050303--