This looks like a bug.

1. You can probably work around it by using jboss 3.0.7 (cvs) or 3.2RC3 and
setting the track-connections-by-tx flag true. This will make jboss keep
track of which connection is associated with a transaction so it won't be
asking firebird for another connection for the same xid.

2. My understanding of the xa spec is that drivers are supposed to be able
to run work on any tx on any connection. However, aside from the
workaround in JayBird that is giving you problems, I have not yet found a
driver that allows you to do this. Does anyone have an explanation of
this?

3. The idle remover is to a large extent an attempt to remove timed out
connections. I'm not sure about the current state of firebird, but it used
to more or less silently drop old connections, leading to problems if you
tried to use them later. Thus dropping old connections and recreating new
up to the min size.

4. Would you possibly have something to demonstrate this problem you could
send?

Thanks
david jencks

On 2003.03.10 04:50 Bart Van Cutsem wrote:
> Hello
>
> We've deployed a JBoss app (JBoss 3.0.6) with accompanying web app using
> a
> Firebird (1.0.2) backend together with Jaybird (latest CVS version, using
> the
> JGDS implementation). I've configured a data source, like the example
> supplied
> with JBoss, with the XaTXConnectionManager. Problem is, after a while we
> get
> loads of DB connections that don't seem to be active but make Firebird
> sort of
> "barf up" after which all connections are abandoned. I've been adding
> some log
> lines here and there to find out what goes on and found out this:
>
> - at a certain moment in time a DB connection is queried for use:
> org.firebirdsql.jdbc.FBDataSource.getConnection()
> - this call walks through some Xa transaction stuff of JBoss itself and
> ends
> up in org.firebirdsql.jca.FBManagedConnection.start(), apparently to
> start a
> global transaction
> - this executes internalstart() and goes on to findIscTrHandle() in
> FBManagedConnection
>
> In findIscTrHandle I see following lines of code:
>
> 1.
> currentTr = mcf.getCurrentIscTrHandle(xid, this, flags);
>
> 2.
> mcf.returnDbHandle(currentDbHandle, cri);
>
> 3.
> if (currentTr.getDbHandle() != currentDbHandle)
> {
> try
> {
> ....
> ....
> currentDbHandle = currentTr.getDbHandle();
>
> I thought that each FBManagedConnection object was associated with 1 DB
> handle
> but only when the first FBManagedConnection object is picked up from the
> pool,
> in statement 3. both handles are the same. When the following
> FBManagedConnection objects are picked up, the handles mismatch, the xid
> seems
> to be the same as for the first FBManagedConnection object, and as a
> result I
> get a number of ManagedConnection objects pointing to the same physical
> connection. When a pool cleanup occurs, one cleanup succeeds, the
> following
> few try to clean up the same connection (which is silently ignored in the
> code), and, off course, the "abandoned" connections stay alive. After a
> while
> Firebird starts acting up before they get garbage collected (if they ever
> get
> garbage collected).
>
>
> Another question: you can configure the connection pool with a min and
> max
> size. But I see all idle connections are always cleaned up when the idle
> remover runs. I thought a pool would grow in size and then shrink again
> when
> some connections stay idle. When all connections are idle, they all are
> cleaned up and the pool refills to minimum size. Is this how it's
> supposed to
> be?
>
> Regards
>
> Bart
>
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>