db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
Date Fri, 11 Jan 2008 07:24:34 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Jørgen Løland updated DERBY-3184:

    Attachment: derby-3184-2b.stat


Thanks for reviewing the patch. I have addressed all your comments. Notes on the revised patch:

AFAIK, inner classes don't have constructors, but I added a setParams method that does the
same. Hence, removed local_*

The methods of the Database interface are used in two scenarios:
1) After getting a connection to the database. This is taken care of by throwing an exception
from setupConnection, and thereby never returning a connection.
2) When the connection is established, i.e. in the constructor of EmbedConnection. The only
Database method used from EmbedConnection is getAuthenticationService, which is handled in
SlaveDatabase by throwing an exception.

I think this should suffice.

I made the storage factory of UpdateServiceProperties volatile. UpdateServiceProperties is
only used during boot of a database, so this should not result in a noticeable performance

I changed the sleep time to 500 millis. The previous setting was used for testing and I forgot
to change it back. 

Patch 2b is ready for review

> 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-2b.diff, derby-3184-2b.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