[
https://issues.apache.org/jira/browse/DERBY-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518400
]
V.Narayanan commented on DERBY-2921:
------------------------------------
>Thanks for the patch, Naryanan.
Thank you for taking a look at the patch Rick and giving me your comments.
>I have an initial question about ReplicationMessage.
>It appears to implement Serializable.
>That means that the exchange protocol relies on both ends of the
>connection being at the same rev level of Derby and perhaps even
>compiled by the same machine.
I learnt some of the nuances of ensuring proper versions for the
serializable objects here.
http://www.javaworld.com/javaworld/jw-02-2006/jw-0227-control.html?page=1
Pls find below the way I think serialization would impact this issue and a
possible resolution.
when replication is attempted between two different versions of Derby.
The incompatibilities caused between releases due to serialization can
be classified into the following
1) Store and retrieve
2) Mixed-release
The store and retrieve happens when a serialized object is stored into a
database and retrieved. This would not be relevant to us. The mixed-release
is what is relevant to us here.
The mixed-release occurs when the two classes on the master and the slave are
at different value of the *suid*.
"Before a serialized object is read, the ObjectInputStream class first computes
the
suid of the local class—the serializable class. It then matches this suid value
against the one stored in the serialized object stream. When these two values
match,
ObjectInputStream reads off the fields in the stream and maps the values into
the
instantiated object. If these two values do not match, ObjectInputStream raises
the
InvalidClassException."
An suid is calculated based on the following factors
1) serializable class's name
2) sorted field names
3) method names of methods and interfaces
4) modifiers.
If I have got it right the the *derby rev* or the *machine* will not impact the
suid.
By machine I mean the *JVM*. I do not think the *machine architecture* would
impact
the compatibility here since the JVM would take care of that.
The incompatibility will rather be due to class incompatibility (i.e.) the
message class
changing between versions.
There are two things that must be done here if any changes are planned in the
subsequent
releases
1) Override the suid.
2) Ensure that changes in subsequent versions are compatible.
As part of addressing the issue pointed out I intend to
1) Override the serialVersionUID
Doing this should should be enough for compatible changes in subsequent
versions. For the
incompatible changes a handshake should suffice but I think this can be delayed
until an
incompatible change is introduced.
>I'm not sure this is what you want, particularly
>since the architecture allows for large webs of Derby nodes, each of which may
>host
>both slaves and masters. I think that the functional spec should address the
>topic
>of version agreement between nodes. For instance, do you envision that newly
>upgraded
>masters will propagate the new Derby rev to their slaves?
> Replication: Add a network service that connects the master and slave Derby
> instances
> -------------------------------------------------------------------------------------
>
> Key: DERBY-2921
> URL: https://issues.apache.org/jira/browse/DERBY-2921
> Project: Derby
> Issue Type: Sub-task
> Components: Services
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: V.Narayanan
> Attachments: Replication_Network_v1.diff, Replication_Network_v1.stat
>
>
> A network connection is required between the master and slave Derby instances
> of a replicated database. The connection will be used to send many kinds of
> messages, including:
> * log records
> * the database (when replication is started)
> * master -> slave commands (like "stop replication")
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
