db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lily Wei (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4653) Avoid unnecessary round-trip for commit/rollback in the client driver
Date Wed, 09 Jun 2010 05:41:12 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Lily Wei updated DERBY-4653:

    Attachment: DERBY-4653-5_withflowcommitrollback.diff

Thanks Kathey for showing me around and making this patch to this stage and explain all the
issues to me.

With this patch, it has the intention fix for Connection.flowcommit() and Connection.flowrollback().
However, when running suites.All, some tests failed. i.e. jdbcapi.StatementPollingTest

The change of the patch which answer the issue Kristian point out. Thanks Kristian for the
looking at the patch and beyond. 

1.	The test gets added to getClientSuite(). The test is only running on regular client, pooled,
and xa datasources.
2.	Change to javadoc as Kristian point out.
3.	Please see comment in BaseJdbcTestCase.java
4.    No need to use the system table as part of test anymore.
5.	getClientTransactonID(Connection conn) is in BaseJdbcTestCase.java so it is closer in suites
than J2EEDataSourceTest and the comment is as following
 "If we are not in a transaction, we don't want to flow commit. We just return"
6.	For flowRollback: Like Kathey said, the original change is only for XAConnection which
does not make sense. With the new change, server flow rollback if isUnitOfWork_ indicates
we are not in a transaction, we return. However, with this change, StatementPoolingTest failed
at org.apache.derbyTesting.functionTests.tests.jdbcapi.StatementPoolingTest.doTestResultSetCloseForHoldability(StatementPoolingTest.java:591)
at      org.apache.derbyTesting.functionTests.tests.jdbcapi.StatementPoolingTest.resTestHoldCursorsOverCommit(StatementPoolingTest.java:522)

I am in the middle of evaluating StatementPoolingTest failed and what change the value of
isUnitOfWork_ when the test trying to close the connection and whether it has to with CachingLogicalConnection40.
Will the test close the connection that is not the connection it performs rollback? What could
be change the value of isUnitOfWork_ within StatementPoolingTest.

> Avoid unnecessary round-trip for commit/rollback in the client driver
> ---------------------------------------------------------------------
>                 Key: DERBY-4653
>                 URL: https://issues.apache.org/jira/browse/DERBY-4653
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Network Client
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Assignee: Lily Wei
>            Priority: Minor
>         Attachments: _sds_0, DERBY-4653-1.diff, DERBY-4653-2.diff, DERBY-4653-3_withrollback.diff,
DERBY-4653-4_withcommitrollbacktest.diff, DERBY-4653-5_withflowcommitrollback.diff, SaveRoundClientDS.java,
> The methods Connection.commit() and Connection.rollback() in the client driver cause
a round-trip to the server even if the commit/rollback is unnecessary (i.e. there is nothing
to commit or roll back).
> Comments suggest (see below) that this can be optimized, such that the commands are flowed
to the server only when required. It can be seen that this optimization has been used other
places in the client driver. Never the less, it must be checked that this optimization doesn't
have side-effects.
> This issue came up in connection with connection pooling, where a pool implementation
always issued a rollback to make sure there was no active transaction on the connection handed
> From Connection.flowCommit:
>         // Per JDBC specification (see javadoc for Connection.commit()):
>         //   "This method should be used only when auto-commit mode has been disabled."
>         // However, some applications do this anyway, it is harmless, so
>         // if they ask to commit, we could go ahead and flow a commit.
>         // But note that rollback() is less harmless, rollback() shouldn't be used in
auto-commit mode.
>         // This behavior is subject to further review.
>         //   if (!this.inUnitOfWork)
>         //     return;
>         // We won't try to be "too smart", if the user requests a commit, we'll flow
a commit,
>         // regardless of whether or not we're in a unit of work or in auto-commit mode.
>         //

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

View raw message