Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <962285747.268171268668467221.JavaMail.jira@brutus.apache.org>
Date: Mon, 15 Mar 2010 15:54:27 +0000 (UTC)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (DBCP-326) Rollback an uncommited transaction on
 return
In-Reply-To: <781642650.251231268535747240.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DBCP-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845380#action_12845380 ] 

Phil Steitz commented on DBCP-326:
----------------------------------

This *should* be current behavior.  In PoolableConnectionFactory#passivateObject, we have

{code}
public void passivateObject(Object obj) throws Exception {
        if(obj instanceof Connection) {
            Connection conn = (Connection)obj;
            if(!conn.getAutoCommit() && !conn.isReadOnly()) {
                conn.rollback();
            }
            conn.clearWarnings();
            if(!conn.getAutoCommit()) {
                conn.setAutoCommit(true);
            }
        }
        if(obj instanceof DelegatingConnection) {
            ((DelegatingConnection)obj).passivate();
        }
    }
{code}

Do you have an example where uncommitted transactions are not being rolled back?  


> Rollback an uncommited transaction on return
> --------------------------------------------
>
>                 Key: DBCP-326
>                 URL: https://issues.apache.org/jira/browse/DBCP-326
>             Project: Commons Dbcp
>          Issue Type: Improvement
>    Affects Versions: 1.3, 1.4
>         Environment: Any
>            Reporter: Adrian Tarau
>            Priority: Critical
>
> DBCP should perform a rollback(should be configurable but by default activated) when the datasource has auto-commit=false. The reason behind is to avoid passing a partial transaction to the next client.
> Rolling back a transaction(in case it wasn't committed of course) adds a guarantee to the validity of a connection borrowed from the pool.

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