Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <9477540.1200036274161.JavaMail.jira@brutus>
Date: Thu, 10 Jan 2008 23:24:34 -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-2b.stat
                derby-3184-2b.diff

=C3=98ystein,

Thanks for reviewing the patch. I have addressed all your comments. Notes o=
n the revised patch:


5:
AFAIK, inner classes don't have constructors, but I added a setParams metho=
d that does the same. Hence, removed local_*

11:
The methods of the Database interface are used in two scenarios:
1) After getting a connection to the database. This is taken care of by thr=
owing an exception from setupConnection, and thereby never returning a conn=
ection.
2) When the connection is established, i.e. in the constructor of EmbedConn=
ection. The only Database method used from EmbedConnection is getAuthentica=
tionService, which is handled in SlaveDatabase by throwing an exception.

I think this should suffice.

12:
I made the storage factory of UpdateServiceProperties volatile. UpdateServi=
ceProperties is only used during boot of a database, so this should not res=
ult in a noticeable performance degradation.

13:
I changed the sleep time to 500 millis. The previous setting was used for t=
esting and I forgot to change it back.=20

Patch 2b is ready for review

> 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-2b.diff, derby-3184-2b.stat, derby-318=
4-bugfix-1a.diff, derby-3184-bugfix-1a.stat
>
>
> 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.