Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jdo-dev@db.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 07 Nov 2006 11:34:33 -0800
From: Craig L Russell <Craig.Russell@Sun.COM>
Subject: Re: JDOHelper.getVersion(Object): Behaviour of jdo versioning
In-reply-to: <454FB48C.6090707@NightLabs.de>
Sender: Craig.Russell@Sun.COM
To: Apache JDO project <jdo-dev@db.apache.org>,
        JDO Expert Group <jdo-experts-ext@Sun.COM>
Message-id: <D24C8AC5-1A9B-4500-8D98-67898C19254C@SUN.com>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature";
 boundary=Apple-Mail-101--62719871; micalg=sha1
References: <454FB48C.6090707@NightLabs.de>

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

Hi Marco,

I agree that the behavior of getVersion is not completely specified =20
by JDO in the current specification.

I'll be happy to add more detail if there is consensus among the =20
experts.

more below...

On Nov 6, 2006, at 2:17 PM, Marco Schulze wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello *,
>
> lately I recognized that JDOHelper.getVersion(Object) returned null in
> StoreLifecycleListener.postStore(...). Therefore, I created a JPOX
> issue: http://www.jpox.org/servlet/jira/browse/CORE-2993
>
> Andy recommended to post here.
>
> Well, I read the paragraphs in the JDO spec about versioning and it
> isn't completely clear to me how it should behave according to the
> spec. It seems, currently, the version of an object is
> created/incremented only at the end of a transaction. In my opinion,
> it would make more sense to create/increment the version as early as
> it's clear that the object will be different after commit:
>
> * In PersistenceManager.makePersistent(...) when a new object is
>   persisted or a detached object attached (hence the
>   StoreLifecycleListener.postStore(...) could already
>   access the correct version).

This makes sense to me.

> * Whenever a living object (which is currently attached to a
>   datastore) is modified for the first time within a transaction.
>   There's no need to modify the version multiple times within one
>   transaction.

This makes sense. I don't know of a case where you would want to =20
change the version number more than once.
>
> For our use case it would be extremely useful, if the behaviour was
> like this, because we would like to use the versioning for our
> client-side caching system. It currently works like this: The server
> registers all relevant JDO LifecycleListeners. Every listener collects
> all Dirty/Attach/Store events that happen within one transaction. When
> the transaction is committed, the collected events are sent to the
> remote clients. Currently, the listeners get the old version (and not
> the one, which the objects will have after commit). This prevents us
> from optimizing our cache system.
>
> More info about our use case can be found here:
> https://www.jfire.org/modules/phpwiki/index.php/HowToClientSideCache
>
> May we kindly ask you to consider our use case and to clarify the
> versioning behaviour in JDO 2.1 as described above?

I've replied including the JDO expert group for their comments.

Regards,

Craig
>
> Best regards, Marco :-)
>
> - --
> ______________________________________________
> ***   http://NoSoftwarePatents-Award.com   ***
> ______________________________________________
> Marco Schulze                   NightLabs GmbH
>                                 Rehlingstr. 6d
>                                 79100 Freiburg
>                                 Germany
>
> eMail:  Marco@NightLabs.de
> Fon:    +49-761-2 111 793
> VoIP:    sip:nlmarco@ekiga.net
> Mobile: +49-172-212 63 80
> Fax:    +49-761-2 111 798
> WWW:    http://www.NightLabs.de
>
> Gesch=E4ftsf=FChrung:
>   Marco Schulze <Marco@NightLabs.de>
>   Niklas Schiffler <Nick@NightLabs.de>
>
> Eintragung:
>   Amtsgericht Freiburg, HRB 6186
> ______________________________________________
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
>
> iD8DBQFFT7SLOn48nLzkjcIRAiuGAJ9+UNdNvqbd12Jo5tbs1L/TSosMcACeNLe5
> ous/B/J4NGUzhzh+ise4CxA=3D
> =3DpCnK
> -----END PGP SIGNATURE-----
>

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-101--62719871
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA3MTkzNDM0WjAjBgkqhkiG9w0B
CQQxFgQU0r5liKkveN9lllm1Nj8zij6v0f4wgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC
WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe2O3yx5iqHh01HW7WK76QMIGHBgsqhkiG
9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ
dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhAe
2O3yx5iqHh01HW7WK76QMA0GCSqGSIb3DQEBAQUABIIBADio/ydKsmKIIP0fLtbNJ0PwNrIFEX++
wfD3TuZQihqBszUjP4Q93NUlGhtOOwXhgayLPaowJg8dbCUl+dqPpEhUDpbc31XjJHh5HAXW2zw4
Foc/CmnrTiE3nuAAr2sz57wtT+0kzZRXWLtcZuCMMChK/NE2QswZZX1HWL20D9S0iDYyNstsD5e7
gkD+u+V8OlHihx3mLGyJx21t6ItFBTnob7XKz3OW6XWSBPv89JXxgTrmdrnzRcX62d+DOlcCcaEO
MZOHIzURj/Zmqh4ZUVJoUKEdX+3LPfXTrh6Gys4ZyKlREAEHfgpPuPMkNiVpQ26kGC1+vcejBfIj
OEJBXEgAAAAAAAA=

--Apple-Mail-101--62719871--