db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-3021) Replication: Add a ReplicationSlave controller that will manage replication on the slave side
Date Wed, 14 Nov 2007 02:48:43 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542309

Øystein Grøvlen commented on DERBY-3021:

Thanks for the patch, Jørgen.  It looks good, but I have a few comments/questions?

1. SlaveController:

   a) I think it is a bit confusing that part of the code assumes that
      logFactory is of type LogToFile, while other code does not.  I
      think it is better to make that assumption up-front in
      startSlave().  That would also mean that you would not have to
      create initializeReplicationSlaveRole() functions in LogFactory
      and ReadOnly.  It can be specific to LogToFile.

   b) I think you should more explicitly state in comments that the
      main idea is that the slave does not time out while waiting for
      a connection from the master.  It will continue doing so until a
      connection is achieved or it is told to shut down.

   c) It is a bit unclear to me how the properties for host name and
      port is to be used.  Is the idea that these properties will be
      set right before trying to boot the slave?  If I am not
      mistaken, these properties will be shared for the entire JVM.
      It seems like that could create problems if two different slave
      databases are booted in parallel?

   d) I think it would be cleaner if setUpConnection() returned a
      boolean that told whether a connection was achieved or not, and
      that this was used to determined whether to continue or not.
      Splitting the logic of testing for inReplicationSlaveMode over
      two functions seems a bit brittle to me.

   e) Will not accesses to inReplicationSlaveMode mode need to be
      synchronized (or the field made volatile)?  Otherwise, I do not
      think there will be any guarantees as to when it will be detected
      that a stop has been requested.

   f) It would be good if the master and the slave could share the
      code to log errors.  I do not see anything slave specific about

   g) Typo in SlaveLogReceiverThread#run: "Exceptions not _cause_ by"

2. LogToFile:

   a) I do not understand the comment for logFileNumber: "current log
      file number other than during boot and recovery time, and by
      initializeReplicationSlaveRole if in slave replication mode,".
      It seems to me that the last sentence "and by ... " does not fit
      in here.

   b) I am not sure I like the steps to prevent others from calling
      your publicized methods when not running as a slave.  If someone
      wants to switch log files for other purposes, should he then
      make another function switchLogFileForOtherPurposes()?  Either
      switchLogFile is part of the public interface, or it is not.  At
      least, I do not feel generating run-time errors is the right
      approach.  I think it is better to just document that you do not
      recommend it for other purposes.  If you really want to hide
      this from the public interface, I guess you can implement a
      subclass of LogToFile in the replication package and let the
      existing methods be protected.

   c) I do not quite understand this comment: 
        // Before recovery is allowed to start, log scans will be
        // allowed unrestricted access to the log files through this
        // method. This is needed because boot() and
        // initializeReplicationSlaveRole() use this method to find
        // the log end.
      As opposed to after recovery is allowed to start, when the
      access is more restricted?

3. messages.xml

   a) For XRE05, don't you have to indicate where the arguments should

> Replication: Add a ReplicationSlave controller that will manage replication on the slave
> ---------------------------------------------------------------------------------------------
>                 Key: DERBY-3021
>                 URL: https://issues.apache.org/jira/browse/DERBY-3021
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions:
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: derby-3021-1.diff, derby-3021-1.stat, derby-3021-1b.diff, derby-3021-1b.stat,
derby-3021-2a.diff, derby-3021-2a.stat
> The replication slave role includes many tasks:
> * set up a network connection with the master
> * receive chunks of log from the master, and parse these into individual log records
> * append log records to the local log file
> * make sure that the recovery process is not allowed to access the logfile we are currently
writing to
> * etc
> This issue is for adding a controller that will start/stop/initiate all services needed
for the replication slave role.

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

View raw message