[
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
derby-3184-2b.diff
Øystein,
Thanks for reviewing the patch. I have addressed all your comments. Notes on
the revised patch:
5:
AFAIK, inner classes don't have constructors, but I added a setParams method
that does the same. Hence, removed local_*
11:
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.
12:
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 degradation.
13:
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: 10.4.0.0
> 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.
