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)
Date: Mon, 06 Feb 2006 16:00:16 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: Cache invalidation
In-reply-to: <43E7D379.6010402@tralfamadore.com>
Sender: Craig.Russell@Sun.COM
Cc: JDO Expert Group <jdo-experts-ext@Sun.COM>,
        Apache JDO project <jdo-dev@db.apache.org>
Message-id: <96D7E819-77DB-41D2-B74A-4FB01C44A07F@Sun.COM>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-283--98056814; micalg=sha1
References: <A6153018-AF90-492D-AFE4-6343109472DF@Sun.COM>
 <43E32981.7010807@artnology.com> <43E64533.5060904@tralfamadore.com>
 <43E6939A.5010502@artnology.com> <43E7D379.6010402@tralfamadore.com>

--Apple-Mail-283--98056814
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	delsp=yes;
	format=flowed

For the record,

I'm not opposed to name changes as long as they are consistent and =20
there is time in the release cycle to implement (trivial). I think =20
the proposal is to change all of the names in the DataStoreCache API =20
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 =20
> "evictById" for those that take OIDs in order to avoid confusion.
>
> To clarify what I mean about persistent nontransactional objects, =20
> see section 5.6.1 of the spec:
> "A persistent-nontransactional instance transitions to persistent-=20
> clean if any managed field
> is accessed when a datastore transaction is in progress. The state =20
> 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 =20
> get an optimistic verification exception at commit time.  So I =20
> guess it is possible to read stale data from the instance in the PM =20=

> cache under a couple of scenarios:
>
> 1. Reading previously loaded fields of a P-NT instance outside of a =20=

> transaction.
> 2. Reading previously loaded fields of a P-NT instance inside an =20
> optimistic transaction.
>
> In these cases, I think you're right that it would be necessary to =20
> hollow the instances in order to be absolutely sure that no stale =20
> data is read after a L2 cache evict().
>
> On the other hand, if you're in an optimistic transaction, don't =20
> you want to retain the previously read values (they represent the =20
> ACID guarantee from the optimistic transaction)?  So the only case =20
> where it might make sense to me is #1 above, and that seems =20
> debatable to me.  Do most people using P-NT objects expect them to =20
> be consistent with the L2 cache at all times?  Or are they expected =20=

> 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 =20
> 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, =20=

>>>> not object ids, so we have to call PM.getObjectById() =20
>>>> beforehand. If no object for that id was present, we're =20
>>>> instantiating a hollow object here only to discard it =20
>>>> afterwards, that's not very effective.
>>>
>>> I'm not quite parsing your "either" here, sorry.  But =20
>>> DataStoreCache.evict() accepts object IDs.  I'm not sure I see =20
>>> the necessity of calling PM.evict() as well, unless you have some =20=

>>> particularly long-lived transactions.
>>
>> We're doing nontransactional reads on long-living objects, so I =20
>> guessed we needed to call PM.evict() to avoid accessing stale =20
>> field data.
>>
>> You're of course right about DatastoreCache.evict() accepting IDs, =20=

>> thanks for pointing that out. I had just seen the same method =20
>> signature, and so I assumed the parameter semantics also being the =20=

>> same.
>>
>> Calling it evictById() probably would be less misleading, even =20
>> more so as a mistake here won't show up immediately. Also, if you =20
>> only have a jar without sourcecode, the signatures are absolutely =20
>> indistinguishable (Which of course is not an excuse for not having =20=

>> read the spec thoroughly enough ;)
>>
>>>> As we really want cache invalidation here, not eviction, this is =20=

>>>> even worse. For this purpose, it would be far more convenient to =20=

>>>> have some method like invalidateCachesFor(Object id) on =20
>>>> PersistenceManagerFactory.
>>>
>>> That's the intention of DataStoreCache.evict().  The semantics =20
>>> are different than PM.evict().
>>
>> Only now I start understanding that I was misled by the word evict=20
>> () for the L2-cache: as the user never gets hold of an L2 cache =20
>> object anyway (a L1-cache object will be created for that), he =20
>> shouldn't need to care whether the L2 cache internally needs to =20
>> throw away (evict) some object in order to invalidate cached =20
>> state. Spec says "/The evict methods are hints to the =20
>> implementation that the instances referred to by the object ids =20
>> are stale and should be evicted from the cache./" It might be nit-=20
>> picking, but I think it would be clearer if the method was called =20
>> invalidateBy=CDd(), which would be natural for some cache interface, =20=

>> and if the explanation said "/that the object state referred to by =20=

>> the object ids should be discarded/"
>>
>> Also, the spec doesn't say anything about DatastoreCache.evict() =20
>> having any impact on P-nontrans instances. So I still need to go =20
>> 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 /=20=

>> both /evict() methods, not only PM.evict()!? The RI JPOX isn't =20
>> doing anything like that, by the way.
>>
>>>> To make our wish complete ;) this method would transition all =20
>>>> non-transactional instances to hollow for that id, for all the =20
>>>> PMs the PMF has given out. All transactional objects with that =20
>>>> id should be transitioned to hollow after their transaction has =20
>>>> completed (either with commit or rollback).
>>>
>>> Persistent nontransactional instances will have to be revalidated =20=

>>> against the datastore (or cache thereof) before being re-enlisted =20=

>>> in a transaction anyway.  The behavior you mention is a good way =20
>>> to implement that, but it doesn't need to be mandated (hollow is =20
>>> not a user-visible state).
>>
>> I'm not sure what you mean by mandating here? I'd just like to =20
>> make sure that invalidated non-transactional instances will reload =20=

>> state upon next read access, without having to iterate all PMs. =20
>> Also, I'd rather not like a call to PM.getObjectById() afterwards =20
>> returning a new Java object for the same id, which I guess is the =20
>> case after calling PM.evict(PM.getObjectById(id)).
>>
>> If a method invalidateById() existed, I'd see the sense of evict() =20=

>> in releasing the associated memory. evict() currently does two =20
>> things at same time: evicting and transitioning to hollow. For =20
>> (distributed) cache invalidation, I find it sensible to desire =20
>> only the latter.
>>
>> Regards,
>> J=F6rg
>
>

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!


--Apple-Mail-283--98056814
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGUDCCAwkw
ggJyoAMCAQICEB7Y7fLHmKoeHTUdbtYrvpAwDQYJKoZIhvcNAQEEBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA1MTIxNTIxNDc0NFoXDTA2MTIxNTIxNDc0
NFowbDEQMA4GA1UEBBMHUnVzc2VsbDEUMBIGA1UEKhMLQ3JhaWcgTGFpcmQxHDAaBgNVBAMTE0Ny
YWlnIExhaXJkIFJ1c3NlbGwxJDAiBgkqhkiG9w0BCQEWFUNyYWlnLlJ1c3NlbGxAU3VuLkNPTTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMXXgEAm88nu8cFbxXSWqTq+GaYpCx/0QSom
8kBbVxpJIURuO4ErLDupeXu6y9+5e7ZKLbeSQE5xbfYPcQR/IhqmYKy5YqRcuzPXREBj2zKEkZph
pNXWpHgMdx9W8dq0Cu2i9Ux/S6c2MuEHrP6gfGGll+b/mzLoO280QHTuE4pcpKntRnwZdGxQ/5l8
IL+eLP+jpJAbYW9C+KNKofZtS6V6R0uzlqTOsEdZvwxZQ4mmPgHoz1+Gjwme/PC5sKvF09MaJDiI
pj9SvZ4CTCgcDZV78J086YwlVbMC0VQotjhu1p42lr8CS33IXLz3OWNrDETCAepah/Dgw2ZZApQ9
9L0CAwEAAaMyMDAwIAYDVR0RBBkwF4EVQ3JhaWcuUnVzc2VsbEBTdW4uQ09NMAwGA1UdEwEB/wQC
MAAwDQYJKoZIhvcNAQEEBQADgYEAKdIkgAWCg2Bi7ocnstfJA4iymTRI2/L4oQx9zvllM9bNJ2cR
cecJIx3HuoHbhPvemh1GExEPgHU+dXSxDmD0BEmPnhSReKCURyslnbMphPZ5kR6USzQFrRa+v0ii
J+SBO9VQYTQWT+xEjmRLM76MfkBFw3IOC9CUkRoYZ88pOoUwggM/MIICqKADAgECAgENMA0GCSqG
SIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQH
EwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZp
Y2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1h
aWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw
NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl
IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls
IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5owHUE
cJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuvPAsH5/Ef
kTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAeZBlyYLf7AgMB
AAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0hjJodHRwOi8vY3Js
LnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDALBgNVHQ8EBAMCAQYwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0GCSqGSIb3DQEBBQUAA4GB
AEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+
hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC
3CEZNd4ksdMdRv9dX2VPMYIDEDCCAwwCAQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh
d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt
YWlsIElzc3VpbmcgQ0ECEB7Y7fLHmKoeHTUdbtYrvpAwCQYFKw4DAhoFAKCCAW8wGAYJKoZIhvcN
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwMjA3MDAwMDE2WjAjBgkqhkiG9w0B
CQQxFgQUR9Wsbbnw0i2O/g/xWzO4QdLLMbEwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBAItmgER7GXYecCf8ElGPm9QzwG5RUiPh
v2qCzF+M12gzIdmb2nKh8OUY2WmzfnjWZFONU2LWvCelHzEW/iB/K3vEGkZmMRfgze12E/UpF0dt
SU/enQHZbXyhGoS1YktvyZFf8cTUGZ2p2uDLURQAx3044wl3e6gH/1tvrZrLhnVyBRLdVPUG3LHK
oA2fx8tTjtzF8xDY4L4YFdmu2vOZJfT0r2Mi61QYG/zMn++HzYPQCZT9WEP2V+5cf6khZW0iphvh
2hsEFkekRj3zZe4v2htInStPYUCP+0pMNgzlUokx1QMQuSxCF7pWZGrpbSvcG0p4s1NoX46owcwY
/aZoKDcAAAAAAAA=

--Apple-Mail-283--98056814--