[
https://issues.apache.org/jira/browse/JDO-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651543#action_12651543
]
Jörg von Frantzius commented on JDO-620:
----------------------------------------
Of course, other people might be using optimistic transactions...
How about maintaining your own field for ordering? Maybe you already have some
kind of lastModification timestamp (provided that only a single datastore is
used for generating those timestamps by means of PM.getServerDate()). Or you
could maintain your own int version field.
> datastore identifier needed for improving replication of objects
> ----------------------------------------------------------------
>
> Key: JDO-620
> URL: https://issues.apache.org/jira/browse/JDO-620
> Project: JDO
> Issue Type: New Feature
> Reporter: Marco
> Fix For: JDO 2 maintenance release 3
>
>
> We - http://www.jfire.org - are using multiple datastores (spread over
> multiple servers accross the world) and have to replicate objects between
> them. Following the documentation in
> http://www.datanucleus.org/products/accessplatform/guides/jdo/replication/ an
> object replication is done this way:
> 1) Detach an object graph from datastore A (using pm.detachCopy(...)).
> 2) Send the object graph to the destination (using Java native serialisation).
> 3) Mark the complete object graph dirty (recursively).
> 4) Attach the object graph to datastore B (using pm.makePersistent(...)).
> Unfortunately, this imposes the following problems: The JDO implementation
> optimizes write operations and thus normally only writes dirty fields to the
> datastore. This is a great feature, but it requires step (3) - making all
> fields dirty manually - to ensure that existing objects are updated
> completely. The negative side effect of this is that the version of the
> object is incremented. That means, the object has a higher version in
> datastore B as in datastore A, even though the object was simply copied and
> thus should have the same version number.
> We therefore kindly request the following extension of the JDO standard - if
> possible for the next release (2.3):
> Every datastore should have an (optional) identifier. This datastore
> identifier should be specified in the persistence.xml properties of the
> PersistenceManagerFactory. The first time such a PersistenceManagerFactory is
> started up, the datastore identifier should be persisted into the datastore
> (maybe a configurable, optional operation). At every following startup, the
> persistent datastore identifier should be compared with the one in the
> persistence.xml. If they do not match, there should be different strategies
> configurable in the persistence.xml:
> * Throw an exception and do not startup the PMF.
> * Copy the value from the persistence.xml into the datastore.
> * Use the value from the persistence.xml without writing it into the
> datastore.
> * Use the value from the datastore and ignore the setting in the
> persistence.xml.
> Please add an API method to the javax.jdo.PersistenceManagerFactory for
> getting the datastore identifier:
> String getDatastoreIdentifier()
> Every detached object should know the datastore identifier of the datastore
> where it was detached. It should be possible to access this value via the
> JDOHelper. Thus, please add the following method to javax.jdo.JDOHelper:
> String getDatastoreIdentifier(Object persistenceCapableObject)
> When calling this method on an object which is currently connected to a
> PersistenceManager, the method returns the same as would this code:
>
> JDOHelper.getPersistenceManager(myObject).getPersistenceManagerFactory().getDatastoreIdentifier();
> When the object has not yet been persisted (i.e. not detached, no
> PersistenceManager assigned), the method
> JDOHelper.getDatastoreIdentifier(...) should return null (just like
> JDOHelper.getVersion(...) does).
> When there is no datastore identifier configured for the
> PersistenceManagerFactory, the result should be an empty String rather than
> null.
> When attaching an object to a datastore, the JDO implementation should check,
> whether this is the same datastore where the object was detached or whether
> it is a different one - i.e. a replication is happening. If the object is
> replicated, all fields should be written - no matter whether they're dirty or
> not. If the object is attached to the same datastore where it was detached
> before, only dirty fields should be written.
> If there was no change (i.e. there is no dirty field), attaching should not
> modify the object's version. This way, a replicated object should always have
> the same version as the original.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
