geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <>
Subject [jira] Closed: (GERONIMO-2688) no-pool and xa-transaction with no caching result in connections being closed before the tx ends.
Date Tue, 26 Jun 2007 18:21:25 GMT


David Jencks closed GERONIMO-2688.

    Resolution: Won't Fix

after thinking about this I think the current behavior is correct.  It's possible for a connector
to supply an XAResource that still works even after the ManagedConnection it came from has
been destroyed (for instance it could delay the actual connection shutdown till the tx is
complete, it could open a new connection for the tx complete, or it could be multiplexing
all work over a single connection).  So to allow for this possibility we should keep the current

With less strange connectors, you should configure transaction caching the purpose of which
is to hold on to the ManagedConnection until the tx completes, and then "close" it.  Depending
on the pool configuration that will put it back in the pool or destroy it.

> no-pool and xa-transaction with no caching result in connections being closed before
the tx ends.
> -------------------------------------------------------------------------------------------------
>                 Key: GERONIMO-2688
>                 URL:
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: connector
>    Affects Versions: 1.1.1, 1.2, 2.0-M5
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: 2.0-M5
> A user has discovered that a connection manager for an outbound resource adapter configured
for no-pool and xa-transaction (with no caching) results in the physical connection being
closed before the transaction can be completed.  This might possibly be a problem with pooling
enabled if there's a long delay between the connection handle being closed and the transaction
ending, during which time the idle remover might fire up and remove the connection.
> This problem can be worked around by enabling transaction-caching which keeps the connection
associated with the transaction until the transaction ends (preventing it from being closed)
or by enabling thread-caching (which ties the connection to the thread more or less indefinitely,
and has not really been tested ever).
> I'll think about whether it is practical to fix this directly. 

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

View raw message