[
https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12876962#action_12876962
]
Lily Wei edited comment on DERBY-4653 at 6/9/10 1:41 AM:
---------------------------------------------------------
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.
J2EEDataSourceTest
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.
BaseJdbcTestCase.java
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?
was (Author: lilywei):
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.
J2EEDataSourceTest
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.
BaseJdbcTestCase.java
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: 10.7.0.0
> 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,
> 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 out.
> 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.
