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-3184) Replication: Connection attempts to a database in slave mode must fail
Date Wed, 09 Jan 2008 11:28:34 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557239#action_12557239

Øystein Grøvlen commented on DERBY-3184:

Thinking a bit more about this patch, I have a few more

11. Have you verified that there is either no way that the different
    BasicDataBase methods can be called on a SlaveDataBase while in
    slave mode, or that for those methods that may be called, no harm
    may happen?

12. The more I think about it, the less sure I am about what you are
    trying to achieve by making local_startParams volatile.  I do not
    think a volatile reference will synchronize access to the referred
    instance.  I see there might be issues with concurrent access to
    UpdateServiceProperties.storageFactory, but I think that needs to
    be solved in that class.

13. A sleep a two seconds in the boot method between checking for
    StorageFactory is unnecessary long I think.  I think a good rule
    of thumb is to make it as short as possible without significantly
    affecting the performance, and I think you can check a reference
    for null more often than every other second without affecting
    performance.  (While a two-second delay of a boot, is probably not
    an issue in production settings, there might be testing scenarios
    with repeated booting of database where the total duration of the
    test may be an issue.)

> Replication: Connection attempts to a database in slave mode must fail
> ----------------------------------------------------------------------
>                 Key: DERBY-3184
>                 URL: https://issues.apache.org/jira/browse/DERBY-3184
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Services
>    Affects Versions:
>            Reporter: Jørgen Løland
>            Assignee: Jørgen Løland
>         Attachments: derby-3184-1.diff, derby-3184-1.stat, derby-3184-2a.diff, derby-3184-2a.stat,
derby-3184-bugfix-1a.diff, derby-3184-bugfix-1a.stat
> When a database 'X' is booted in slave mode, the call to  Monitor.startPersistentService("X",...)
will not complete because the call gets stuck in LogToFile#recover. This is intentional.
> For as long as startPersistentService is blocked, however, other threads that try to
connect to 'X' (effectively calling Monitor.findService("X", ...)) will also hang. This is
unacceptable, and needs to raise an error.

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

View raw message