db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: JDOHelper.getVersion(Object): Behaviour of jdo versioning
Date Tue, 07 Nov 2006 19:34:33 GMT
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 <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=
> =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!


Mime
View raw message