db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3016) Replication: Add code that parses a chunk of log records (byte[]) into individual log records
Date Mon, 27 Aug 2007 17:19:30 GMT

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

Dag H. Wanvik commented on DERBY-3016:
--------------------------------------

The patch looks good to me. 

It provides an abstraction for accessing the incoming log records. The
'data' and 'optional data' fields are copied once more before they can be
accessed by the slave redo.
This seems unncessary since the lifetime of the objects created is
shorter than the underlying buffer source (logToScan), but may be
convenient given the usage intended: One needs to get at a byte[]
array for the data to be present in the  shape and form as expected
for the for the reDo step, perhaps? Guessing..

Nits, pick and choose :)

- Class level javadoc: Would be good with a @see tag in the reference
  to point to the class definining the record format, and perhaps omit
  the reduncancy here?
- "When a new chunk of log record is to be scanned"
                                *s
- form -> from
- The information on this last read
                  ** in
- only one thread will be receiving
       ********** per database being replicated ? So
       ReplicationLogScan is not really a singleton, right?
- init(): Missing @param
- next(): Under "side effect include": Mention currentPosition,
  perhaps? Then you can drop "include".
- successfull -> successfully
- // ..In theory,
  // it should not be possible for currentPosition to be
  I woudl drop "in theory", it is an invariant, right?
  And you do check for it in the get methods.
- getInstant plus the other getters:
  "NoSuchElementException" : you could add that this should only
  happen under wrong usage of this class, perhaps.
- retrieve methods: I would suggest the wording "increments
  currentPosition" over the two present wordings ("adds",
  "increases").
- retreiveBytes: missing @param tags

Code:
- retrieve methods: sanity messages: suggest blanks around "+"
  operator for readbility.
- retrieveLong: deserialization: why use both (long) casting and "&
  xxL" widening methods? Suggest sticking to explicit cast.


> Replication: Add code that parses a chunk of log records (byte[]) into individual log
records 
> ----------------------------------------------------------------------------------------------
>
>                 Key: DERBY-3016
>                 URL: https://issues.apache.org/jira/browse/DERBY-3016
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions: 10.4.0.0
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: slave_logscan_1.diff, slave_logscan_1.stat
>
>
> The derby instance that has the slave role for a database 'x' has to redo log records
sent from the master. These log records are sent in chunks as a byte[]. To be useful to the
slave, these chunks of log records must be parsed into individual log records. 
> The actual format of the received log record chunks is defined by the replication log
buffer (see DERBY-2926).

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


Mime
View raw message