[
https://issues.apache.org/jira/browse/JDO-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Jefferson updated JDO-620:
-------------------------------
Fix Version/s: (was: JDO 2 maintenance release 3)
Moving out of scope for 2.3 since not enough background scoping done on this
change and would be nice to get JDO2.3 out. Add more thoughts when you have
time so then it could be early JDO2.4
> 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
>
> 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.
