db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guido Anzuoni (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JDO-620) datastore identifier needed for improving replication of objects
Date Wed, 17 Dec 2008 22:50:44 GMT

    [ https://issues.apache.org/jira/browse/JDO-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657593#action_12657593

Guido Anzuoni commented on JDO-620:

IMHO I think that attach/detach feature is primarily intended to be used within the same datastore.
Don't know exactly what the original spec says on the topic but I think that version (that
is there to support - local - optimistic transactions)
should not be replicated literally.
I mean that if an object O is detached from a PM1 of datastore D1 and attached to PM2 of datastore
D2, JDO should behave exactly as
the object with the same identity of O is loaded in PM2 and "manually" updated by the application.
In this sense, maybe yes, JDO should know the PMF from where O was detached in order to apply
correct management of
Coming back to the topic, I think that version management should not be stretched to implement
multi-way replication.
Version is there to support optimistic transactions.
Support for objects replication is a whole different job and I think it should be designed
from scratch (there should be consolidated literature on this topic, i.e. algorithms - Arjuna
had this feature, if I remember well).
And it should be an optional feature.

> 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
>   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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message