[
https://issues.apache.org/jira/browse/DERBY-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12520588
]
Rick Hillegas commented on DERBY-2921:
--------------------------------------
Øystein> If I understand correctly, hard-coding the SerialVersionUUID, will
mean that when one later change the serialization form, one will have to
manually update the SerialVersionUUID.
If I were coding this myself, my instinct would be to use Externalizable rather
than Serializable. As its very first task, writeExternal() would stamp a
version id on the serialization stream. Symmetrically, as its very first task,
readExternal() would read the stamped version id--and switch based on the
actual version id. I find this approach is very flexible. And you are right,
the version id has to change when the serialized form is altered--regardless of
whether the solution is programmed using Serializable or Externalizable.
Øystein> Would not that imply that as long as the format of the message does
not change, running different versions of the master and the slave will work?
I'm not following you. How would you handle the problem described in my comment
on August 8: The master hard-uprades and the transactional work done as part of
hard upgrade is replayed into the down-rev slave database. Now the slave
database thinks that it is at a higher rev than the actual Derby code on the
slave machine. What will happen if you have to failover to this inconsistent
slave?
> 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.
