Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <7641070.1661273519351346.JavaMail.jira@thor>
Date: Mon, 10 May 2010 15:22:31 -0400 (EDT)
From: "Jamie goodyear (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Issue Comment Edited: (FELIX-2280) To much code duplication
 in DefaultJDBCLock, OracleJDBCLock and MySQLJDBCLock
In-Reply-To: <27264362.53661271181175273.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/FELIX-2280?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1286=
5851#action_12865851 ]=20

Jamie goodyear edited comment on FELIX-2280 at 5/10/10 3:21 PM:
----------------------------------------------------------------

Hi Christian,

In my testing I came across an issue restoring service after a DB failure. =
The test case can be reproduced as follows:

1. Start up DB.
2. Start first instance of Karaf, configured to DB. This should become the =
Master.
3. Start second instance of Karaf, also configured to DB. This should becom=
e a Slave.
4. Stop the DB.
5. Observe that both instances of Karaf are hung waiting for DB lock.
6. Start the DB again.
7. Observe that both instances of Karaf are still hung.

One of these instances should have become the Master upon return of the DB =
service. I reproduced this using the Oracle JDBC Lock.

Cheers,
Jamie

Note: The same behavior is observed while using the Default JDBC Lock as we=
ll (Derby).

      was (Author: jgoodyear):
    Hi Christian,

In my testing I came across an issue restoring service after a DB failure. =
The test case can be reproduced as follows:

1. Start up DB.
2. Start first instance of Karaf, configured to DB. This should become the =
Master.
3. Start second instance of Karaf, also configured to DB. This should becom=
e a Slave.
4. Stop the DB.
5. Observe that both instances of Karaf are hung waiting for DB lock.
6. Start the DB again.
7. Observe that both instances of Karaf are still hung.

One of these instances should have become the Master upon return of the DB =
service. I reproduced this using the Oracle JDBC Lock.

Cheers,
Jamie
 =20
> To much code duplication in DefaultJDBCLock, OracleJDBCLock and MySQLJDBC=
Lock
> -------------------------------------------------------------------------=
----
>
>                 Key: FELIX-2280
>                 URL: https://issues.apache.org/jira/browse/FELIX-2280
>             Project: Felix
>          Issue Type: Improvement
>          Components: Karaf
>    Affects Versions: karaf-1.4.0
>         Environment: All
>            Reporter: Christian M=C3=BCller
>            Assignee: Jamie goodyear
>         Attachments: FELIX-2280.patch, FELIX-2280.patch, FELIX-2280.patch=
, FELIX-2280.patch
>
>
> org.apache.felix.karaf.main.DefaultJDBCLock, org.apache.felix.karaf.main.=
MySQLJDBCLock and org.apache.felix.karaf.main.OracleJDBCLock has to much co=
de duplications. I propose a solution like in ActiveMQ [package org.apache.=
activemq.store.jdbc.adapter|http://svn.apache.org/viewvc/activemq/trunk/act=
ivemq-core/src/main/java/org/apache/activemq/store/jdbc/adapter/].
> And we should implement some unit tests for it.
> If it's fine for you, I will try to improve this part of karaf and provid=
e a patch for it.

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