[
https://issues.apache.org/jira/browse/DERBY-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540509
]
Daniel John Debrunner commented on DERBY-2872:
----------------------------------------------
>> Is there any reason to put these replications commands on the class/command
>> used to control the network server? They don't fit naturally there, why not
>> a replication specific class/command? From the functional spec I can't see
>> any requirement that the master or slave are running the network server, so
>> I assume I can have replication working with embedded only systems.
> Implementing this in the network server means that the blocking startslave
> command will run in a thread on the same vm as the server.
That's an implementation detail, wouldn't it be better to have a separate class
for replication commands, even if they use the same implementation code?
Does that mean that this replication does not supported embedded only use, a
network server must be booted? Good to state that in the spec, if so.
> Thus, the slave does not contact the master - it only sends a message using
> the existing connection.
The functional spec says "The slave tries to reestablish the connection with
the master. " - I guess this really means the slave waits for a master to
re-connect to it.
> Add Replication functionality to Derby
> --------------------------------------
>
> Key: DERBY-2872
> URL: https://issues.apache.org/jira/browse/DERBY-2872
> Project: Derby
> Issue Type: New Feature
> Components: Miscellaneous
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: master_classes_1.pdf, poc_master_v2.diff,
> poc_master_v2.stat, poc_master_v2b.diff, poc_slave_v2.diff,
> poc_slave_v2.stat, poc_slave_v2b.diff, poc_slave_v2c.diff,
> proof-of-concept_v2b-howto.txt, proof_of_concept_master.diff,
> proof_of_concept_master.stat, proof_of_concept_slave.diff,
> proof_of_concept_slave.stat, replication_funcspec.html,
> replication_funcspec_v2.html, replication_funcspec_v3.html,
> replication_funcspec_v4.html, replication_funcspec_v5.html,
> replication_funcspec_v6.html, replication_script.txt, slave_classes_1.pdf
>
>
> It would be nice to have replication functionality to Derby; many potential
> Derby users seem to want this. The attached functional specification lists
> some initial thoughts for how this feature may work.
> Dag Wanvik had a look at this functionality some months ago. He wrote a proof
> of concept patch that enables replication by copying (using file system copy)
> and redoing the existing Derby transaction log to the slave (unfortunately, I
> can not find the mail thread now).
> DERBY-2852 contains a patch that enables replication by sending dedicated
> logical log records to the slave through a network connection and redoing
> these.
> Replication has been requested and discussed previously in multiple threads,
> including these:
> http://mail-archives.apache.org/mod_mbox/db-derby-user/200504.mbox/[EMAIL
> PROTECTED]
> http://www.nabble.com/Does-Derby-support-Transaction-Logging---t2626667.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
