Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: local policy)
From: Mario-Leander Reimer <leander.reimer@vva-networks.de>
To: "users@jackrabbit.apache.org" <users@jackrabbit.apache.org>
Date: Fri, 13 Mar 2009 16:29:10 +0100
Subject: DB connection issue with JackRabbit 1.5.3, JBoss 4.2.3 and mySQL
Thread-Topic: DB connection issue with JackRabbit 1.5.3, JBoss 4.2.3 and
 mySQL
Thread-Index: Acmj8HT4kRePCBP7QCawx8a5sjg5dQ==
Message-ID: <508F74BC296D494E9A4A983C854E1EA70501BF2AF0@d-ex-01.vva.local>
Accept-Language: de-DE
Content-Language: de-DE
acceptlanguage: de-DE
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi everyone,

following situation: I have JackRabbit 1.5.3 running under JBoss 4.2.3 (wit=
h JCA connector), using a XA DB connection datasource that connects to a my=
SQL 5.1.30 instance.

So far I have been using either ..bundle.MySqlPersistenceManager or the ..d=
b.JNDIDatabasePersistenceManager and configured to get the connection from =
the JNDI datasource. OK.

Question 1: What's the recommended PM? Is the bundle MySqlPersistenceManage=
r any faster or slower than the JNDIDatabasePersistenceManager?

The issue now is: Every morning, after a long idle period, the DB connectio=
n JackRabbit is holding has been closed, probably by mySQL after the defaul=
t period I assume, and JR is not able to recover from that, using either of=
 the PMs. What can I do? How can I change my configuration so this doesn't =
happen anymore?

1. I don't want to increase the mySQL idle timeout!

2. I know the bundle PM has a reconnect feature, but when it tries to do so=
, it's throwing exception and complaining about autoCommit not being possib=
le for managed connections. Should I use a local-tx datasource instead of t=
he XA?

3. With the JNDIDatabasePersistenceManager it just doesn't reconnect and I =
need to restart.

Question 2: Is there any point of using a container managed datasource, sin=
ce it seems JR is using only one connection from it (is this right)? Should=
 I just configure the DB connection for JR in the repository.xml?

I need XA transaction because I have another DB datasource as well as the J=
CR datasource and I obviously want the writes to both datasources to commit=
 together or be rolled back properly.

Does configuring the JR connection in the repo xml harm this behavior in an=
y way?

OK, hope someone can give me some advice.

Thanks,
Leander


VVA Networks GmbH

Mario-Leander Reimer
Dipl.-Inf. (FH)
Teamleitung Publishing Solutions
---------------------------------------------------------------------------
VVA Networks GmbH
: medien mit zukunft
Geisenhausenerstra?e 15-17
81379 M?nchen
Deutschland
---------------------------------------------------------------------------
Fon:    +49 89 2000375-610
Fax:    +49 89 2000375-699
Mobil:  +49 173 5883541
---------------------------------------------------------------------------
leander.reimer@vva-networks.de
www.vva-networks.de

-----------------------------------------------------------------------
HRB 33884 D?sseldorf
Gesch?ftsf?hrer Rolf Christian Kassel
-----------------------------------------------------------------------
Ein Unternehmen der VVA Kommunikation
http://www.vva.de
-----------------------------------------------------------------------
omnisuite(r) - integrate. automate. communicate.
http://www.omnisuite.de
-----------------------------------------------------------------------

Diese Nachricht (inklusive aller Anh?nge) ist vertraulich. Sie darf
ausschlie?lich durch den vorgesehenen Empf?nger und Adressaten gelesen,
kopiert oder genutzt werden. Sollten Sie diese Nachricht versehentlich
erhalten haben, bitten wir, den Absender (durch Antwort-E-Mail) hiervon
unverz?glich zu informieren und die Nachricht zu l?schen. Jede unerlaubte
Nutzung oder Weitergabe des Inhalts dieser Nachricht, sei es vollst?ndig
oder teilweise, ist unzul?ssig.

This message (including any attachments) is confidential and may be
privileged. It may be read, copied and used only by the intended recipient.
If you have received it in error please contact the sender (by return
E-Mail) immediately and delete this message. Any unauthorised use or
dissemination of this message in whole or in part is strictly prohibited.