You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Marco Schulze <Ma...@NightLabs.de> on 2006/11/06 23:17:48 UTC
JDOHelper.getVersion(Object): Behaviour of jdo versioning
-----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).
* 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.
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?
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äftsführung:
Marco Schulze <Ma...@NightLabs.de>
Niklas Schiffler <Ni...@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=
=pCnK
-----END PGP SIGNATURE-----
Re: JDOHelper.getVersion(Object): Behaviour of jdo versioning
Posted by Marco Schulze <Ma...@NightLabs.de>.
Hello Craig,
thank you very much for your quick reply! I'm really happy that you
agree :-)
There's only one thing that just popped into my mind:
> * 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
> change the version number more than once.
http://www.jpox.org/docs/1_1/metadata_reference.html#version describes
that there is one versioning strategy which would require a different
behaviour: state-image (not yet supported by jpox).
In this case, multiple modifications of the object would result in
different state images. Therefore, this would be the only versioning
strategy, which might require multiple calculations of the version
within one transaction. IMHO this is not a problem, though, because the
version could be calculated lazily (and thus not be calculated before
the end of a transaction, if no call to JDOHelper.getVersion(...)
occurs) and of course other optimizations might be used as well (e.g.
caching the hashes of the fields, so that only those fields require
recalculation that really changed).
Best regards, Marco :-)
Re: JDOHelper.getVersion(Object): Behaviour of jdo versioning
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi Marco,
I agree that the behavior of getVersion is not completely specified
by JDO in the current specification.
I'll be happy to add more detail if there is consensus among the
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
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äftsführung:
> Marco Schulze <Ma...@NightLabs.de>
> Niklas Schiffler <Ni...@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=
> =pCnK
> -----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!