db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
Date Fri, 07 Dec 2007 14:23:43 GMT

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

Øystein Grøvlen commented on DERBY-3184:
----------------------------------------

Thanks for the patch, Jørgen.  

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).  However, I see that the current design would need a rewrite
to in order to be able to avoid this, since there is currently no way
of getting hold of a service where the booting has not completed.
Currently, if you try to find a service during booting, you will hang
waiting for the boot to complete.

I have not looked into the details, but it seems that it should be
possible to get a handle to a Database that is booting, through
BaseMonitor.findModule with some extra wiring in a static method in
Monitor.  A Database object is definitely a better fit for replication
logic.  However, I have not thought about the consequences of
providing such an access point.  It would be useful if someone with
more experience with the Monitor framework, could provide a
recommendation here.

Given the approach of the current patch, I wonder whether it would be
better to isolate the "pollution" of replication logic that is
currently spread across the BaseMonitor and TopService classes, to
just the TopService class.  It seems like all the necessary
information should be available there.

Some minor nits:

   - Why are the added methods in TopService protected and not just
     package private?
   - Indentation in Monitor.findService looks a bit awkward due to
     the line break before 'throws'.

> 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.


Mime
View raw message