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] Issue Comment Edited: (DERBY-4653) Avoid unnecessary round-trip for commit/rollback in the client driver
Date Fri, 11 Jun 2010 05:19:15 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877314#action_12877314
] 

Lily Wei edited comment on DERBY-4653 at 6/11/10 1:17 AM:
----------------------------------------------------------

I was looking at why StatementPoolingTest.test.doTestResultSetCloseorHoldability failure issue.
When the first time it gets to this signature, conn.rollback() will flow. At that time CachingLoginalConnection40.physicalConnection_.inUnitofWork_
is false which is expected.
However, when it gets to conn.close() which call StatementCacheInteractor.closeOpenLogicalStatements
line 224 logicalStatement.close() the variable inUnitofWork_ become true. I am not familiar
with closeOpenLogicalStatements synchronized method. Does this only get change in some sort
of multi-thread situation?

When StatementPoolingTest get to doTestResultSetCloseorHoldability() the second time, the
variable of physicalConnection_.inUnitofWork_ remains false when close are completely done.

What need to change so we can rely on inUnitofWork_ to be the flag to decide whether we can
flow rollback or not? 



      was (Author: lilywei):
    I was looking at why StatementPoolingTest.test.doTestResultSetCloseorHoldability failure
issue.
When the first time it gets to this signature, conn.rollback() will flow. At that time CachingLoginalConnection40.physicalConnection_.isUnitofWork_
is false which is expected.
However, when it gets to conn.close() which call StatementCacheInteractor.closeOpenLogicalStatements
line 224 logicalStatement.close() the variable isUnitofWork_ become true. I am not familiar
with closeOpenLogicalStatements synchronized method. Does this only get change in some sort
of multi-thread situation?

When StatementPoolingTest get to doTestResultSetCloseorHoldability() the second time, the
variable of physicalConnection_.isUnitofWork_ remains false when close are completely done.

What need to change so we can rely on isUnitofWork_ to be the flag to decide whether we can
flow rollback or not? 


  
> 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, DERBY-4653-6_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.


Mime
View raw message