Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <6370700.1199778939292.JavaMail.jira@brutus>
Date: Mon, 7 Jan 2008 23:55:39 -0800 (PST)
From: =?utf-8?Q?J=C3=B8rgen_L=C3=B8land_=28JIRA=29?= <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Updated: (DERBY-3184) Replication: Connection attempts to a
 database in slave mode must fail
In-Reply-To: <30645186.1194428330700.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/DERBY-3184?page=3Dcom.atlassia=
n.jira.plugin.system.issuetabpanels:all-tabpanel ]

J=C3=B8rgen L=C3=B8land updated DERBY-3184:
---------------------------------

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

The attached patch, v2a, adds a new implementation of Database to Derby. Th=
e new implementation is called SlaveDatabase and is booted if startSlave=3D=
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.=20

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

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

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/SlaveFa=
ctory.java

Minor changes

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

* I have also run all the junit tests on a setup where SlaveDatabase was ha=
rdcoded to be used instead of BasicDatabase. This works [1], indicating tha=
t 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 throw=
n (from the rawstore module). Since the store modules of SlaveDatabase are =
booted in a separate thread, these exceptions are only reported in derby.lo=
g, not reported to the caller of connect '...'. However, when SlaveDatabase=
 in not hardcoded to be used, this can only happen when dataEncryption=3Dtr=
ue and startSlave=3Dtrue are specified at the same time. This combination w=
ill 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=C3=B8rgen L=C3=B8land
>            Assignee: J=C3=B8rgen L=C3=B8land
>         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.s=
tat
>
>
> When a database 'X' is booted in slave mode, the call to  Monitor.startPe=
rsistentService("X",...) will not complete because the call gets stuck in L=
ogToFile#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.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.