db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2921) Replication: Add a network service that connects the master and slave Derby instances
Date Wed, 08 Aug 2007 10:04:59 GMT

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


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 

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

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

View raw message