[
https://issues.apache.org/jira/browse/DERBY-3184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561329#action_12561329
]
oysteing edited comment on DERBY-3184 at 1/22/08 4:49 AM:
-----------------------------------------------------------------
Error handling in SlaveDatabase looks good, but since ReplicationLogger does
not contain any state, I think it would be better to make logError static.
Then you would not have to instantiate in every class where you need error
handling.
It also worries me a bit that you had to import StandardException in
DRDAConnThread, but that is probably not your fault. It seems to me that
validateSecMecUSRSSBPWD() does things that maybe should have been handled
inside the database. Anyway, we should make sure to test this case. That is,
try to connect to a slave database using SecMecUSRSSBPWD.
A minor issue: In EmbedConnection: No need to cast se, it is already a
StandardException.
was (Author: oysteing):
Error handling in SlaveDatabase looks good, but since ReplicationLogger
does not contain any state, I think it would be better to make logError static.
Then you would not have to instantiate in every class where you need error
handling.
It also worries me a bit that you had to import StandardException in
DRDAConnThread, but that is probably not your fault. It seems to me that
validateSecMecUSRSSBPWD() does things that maybe should have been handled
inside the database. Anyway, we should make sure to test this case. That is,
try to connect to a slave database using SecMecUSRSSBPWD.
A minor issue: In EmbedConnection: No need to case se, it is already a
StandardException.
> 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-2c.diff, derby-3184-3a.diff,
> derby-3184-3a.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.
