[
https://issues.apache.org/jira/browse/DERBY-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512541
]
Dag H. Wanvik commented on DERBY-2926:
--------------------------------------
> * It will be very easy to recycle the ReplicationLogRecord objects
> that make up the linked list. Once the log-information in an object
> has been shipped to the slave, the object could be put in a pool of
> recycled objects. This would significantly reduce the number of
> ReplicationLogRecord objects that must be created and garbage
> collected, but may increase the memory usage since the objects in
> the pool are not removed from memory. *Is recycling considered good
> or bad practice?*
At this years Java One, the Sun JVM garbage collector people talked a
lot about how cheap object creation and garbage collection is iff:
- objects are short-lived
- objects are read-only (use final if possible!)
- objects are short
(see http://developers.sun.com/learning/javaoneonline/2007/pdf/TS-2906.pdf)
So whether recycling will be good depends on the nature of the
objects. Perhaps a micro benchmark may be useful to determine
this. Another approach here would be to use a large circular byte buffer and
administer space in it yourself.
How do you imagine flow control if the network gets slow? Would you
block a transaction whose record would overflow the buffer?
> 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.
