commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yossi Shaul (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DBCP-399) Rollback on PoolableConnectionFactory.passivateObject() has to be configuration controlled.
Date Thu, 19 Dec 2013 16:04:07 GMT

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

Yossi Shaul commented on DBCP-399:
----------------------------------

The same is true with the passivate object calling conn.setAutoCommit(true); whenever autocommit
is disabled.

> Rollback on PoolableConnectionFactory.passivateObject() has to be configuration controlled.
> -------------------------------------------------------------------------------------------
>
>                 Key: DBCP-399
>                 URL: https://issues.apache.org/jira/browse/DBCP-399
>             Project: Commons Dbcp
>          Issue Type: Bug
>    Affects Versions: 1.4
>         Environment: Any databases, especially on those, where the rollback calls are
costly.
>            Reporter: Girish Adat
>              Labels: easyfix, performance
>
> In certain databases like IBM DB2, the rollback calls are costly. Also, on any database,
this avoids an unnecessary call to DB upon returning a connection back to pool, and thus enhances
the application performance.
> So it would be good, if there is an optional configuration parameter that controls the
"rollbackAsCleanUpAction" behaviour. This can be made "false" (can be true by default, aiming
current users) if the application can guarantee itself that, no connection is returned to
the pool without an explicit call to commit() or rollback(), even in the case of a non-readonly
and non-autocommit connection.
> A few more bits: This caused a 1/11, i.e. approx 10% performance loss in our application.
Hence making this a bug (a performance issue), and not a Feature Request / Improvement!



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message