[
https://issues.apache.org/jira/browse/DERBY-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512879
]
Jørgen Løland commented on DERBY-2926:
--------------------------------------
>How do you imagine flow control if the network gets slow? Would you
>block a transaction whose record would overflow the buffer?
There are at least two simple alternatives for how to handle a full replication
buffer:
* Stop replication
* Block transactions
I think the first alternative would be the better one since blocking
transactions would mean no availability. This is the exact opposite of what we
want to achieve with replication.
The functional spec of DERBY-2872 states that resuming replication after it has
been stopped is a good candidate for extending the functionality. Once that
issue has been addressed, we have a third alternative if the buffer gets full:
* Stop replication for now, but store the log files so that replication can be
resumed later.
> Replication: Add a log buffer for log records that should be shipped to the
> slave
> ---------------------------------------------------------------------------------
>
> Key: DERBY-2926
> URL: https://issues.apache.org/jira/browse/DERBY-2926
> Project: Derby
> Issue Type: Sub-task
> Components: Store
> Affects Versions: 10.4.0.0
> Reporter: Jørgen Løland
> Assignee: Jørgen Løland
>
> When a Derby instance has the master role for a database, log records are
> shipped to the slave to keep it up to date. A buffer is needed because the
> log records should not be shipped one at a time. Also, writing the log
> records to a buffer instead of sending them immediately removes the network
> communication from the critical path for the transaction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
