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] Updated: (DERBY-3184) Replication: Connection attempts to a database in slave mode must fail
Date Tue, 08 Jan 2008 07:55:39 GMT

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

Jørgen Løland updated DERBY-3184:
---------------------------------

    Attachment: derby-3184-2a.diff
                derby-3184-2a.stat

The attached patch, v2a, adds a new implementation of Database to Derby. The new implementation
is called SlaveDatabase and is booted if startSlave=true is specified in the connection url.
The following files are modified:

A      java/engine/org/apache/derby/impl/db/SlaveDatabase.java
M      java/engine/org/apache/derby/modules.properties

The new Database implementation "SlaveDatabase" to Derby. 

M      java/engine/org/apache/derby/impl/db/BasicDatabase.java

Removed the old "if (inReplicationSlaveMode) throw exception" code. This is now handled in
SlaveDatabase. 

M      java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java

Adds slave replication pre mode

M      java/engine/org/apache/derby/iapi/services/replication/slave/SlaveFactory.java

Minor changes

Testing:
--------
* all tests passed

* I have also run all the junit tests on a setup where SlaveDatabase was hardcoded to be used
instead of BasicDatabase. This works [1], indicating that the new implementation works *after*
the database has left slave mode (i.e., after the failover command has been run)

[1] Some encryption tests fail because they expect an exception to be thrown (from the rawstore
module). Since the store modules of SlaveDatabase are booted in a separate thread, these exceptions
are only reported in derby.log, not reported to the caller of connect '...'. However, when
SlaveDatabase in not hardcoded to be used, this can only happen when dataEncryption=true and
startSlave=true are specified at the same time. This combination will not be allowed.


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


Mime
View raw message