[
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
questions/comments:
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: 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-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.
