[
https://issues.apache.org/jira/browse/DERBY-3071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øystein Grøvlen updated DERBY-3071:
-----------------------------------
Derby Info: (was: [Patch Available])
Thanks for the update, Jørgen.
Committed patch, derby-3071_continuous-recovery_1c.diff, as revision 588210.
With respect to 1d), I would think it would be less confusing if the assignment
was put inside the if block where it is needed. You may consider that for
future follow-up patches. Actually, I am not sure the assignment is needed
since it seems to me that when (logEnd == LogCounter.INVALID_LOG_INSTANT),
logFileNumber will not have changed since boot.
> Replication: Modify logging subsystem for slave replication mode
> ----------------------------------------------------------------
>
> Key: DERBY-3071
> URL: https://issues.apache.org/jira/browse/DERBY-3071
> Project: Derby
> Issue Type: Sub-task
> Components: Services, Store
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
> Attachments: derby-3071_continuous-recovery_1a.diff,
> derby-3071_continuous-recovery_1a.stat,
> derby-3071_continuous-recovery_1b.diff, derby-3071_continuous-recovery_1c.diff
>
>
> When a database is booted in slave replication mode, it should apply log
> records received from the master but must not generate log by itself. As
> described in the functional specification (see DERBY-2872), a database booted
> in slave mode should enter LogToFile#recover, but not leave this method until
> the database is no longer in slave mode.
> The current plan for this issue is to modify LogToFile the following ways:
> * LogToFile is put in slave mode automatically during boot (if property
> SlaveFactory.SLAVE_MODE is set, see DERBY-3021), but a method is needed to
> take LogToFile out of recovery mode.
> * SlaveFactory (DERBY-3021) will receive log records from the master and use
> LogToFile#appendLogRecord to write these to disk. While in slave mode, only
> SlaveFactory will be allowed to append log records.
> * The thread running LogToFile#recover will recover (redo) one log file at a
> time (like now), but will not be allowed to open a log file X until that file
> is no longer being written to. Thus, while appenLogFile writes to logX.dat,
> recover will be allowed to read all log files up to and including logX-1.dat
> but will then have to wait until appendLogRecord starts writing to logX+1.dat.
> All the described changes will only apply when in slave mode
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
