[
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549456
]
Daniel John Debrunner commented on DERBY-3184:
----------------------------------------------
> I must admit I feel a bit uneasy introducing knowledge about
> replication into the Monitor which currently does not seem to have any
> knowledge about databases (except something called a persistent
> service).
+1 to the uneasiness about adding replication knowledge to the monitor. I think
Derby (&Cloudscape) has benefited over the years from isolating components from
each other. Some future direction might to replace Derby's monitor with some
other existing open-source IoC system that has a cleaner design and by
definition will be separated from knowledge of Derby's code.
> 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
>
>
> 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.
