db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jørgen Løland (JIRA) <j...@apache.org>
Subject [jira] Commented: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
Date Mon, 10 Dec 2007 13:49:43 GMT

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

Jørgen Løland commented on DERBY-3184:
--------------------------------------

Øystein and Dan. 

In light of your comments, I agree that this is not the right
solution to the problem. I have a new suggestion for how to solve
this without touching the monitor.

* Add a new implementation of Database, called something like
  SlaveDatabase

* Modify canSupport of all instances of Database so that
  SlaveDatabase is booted if slave replication is specified

* When booted, SlaveDatabase will spawn a new tread that calls
  BasicDatabase#boot(). This thread will be blocked in
  LogToFile#recover(). After spawning the thread,
  SlaveDatabase#boot finishes. Calls to Monitor#findService will
  return the SlaveDatabase object, but all method calls will
  result in an SQL Exception with state
  CANNOT_CONNECT_TO_DB_IN_SLAVE_MODE:

  public LanguageConnectionContext setupConnection(..) {
      if (inSlaveMode) {
          throw StandardException (SQLState.CANNOT_CONNECT...)
      }
      return basicDatabase.setupConnection(...);
  }
  

> 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