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-4314) With derby client setTransactionIsolation executes and commits even if isolation has not changed
Date Fri, 30 Apr 2010 15:42:54 GMT

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

Lily Wei updated DERBY-4314:

    Attachment: DERBY-4314-7-withoutpiggybacking.diff

This is the version I intent to submit for this fix.
This fix avoid assertion like DERBY-4343 by short-circuiting setTransactionIsolation. 
For case as users obtaining the pooled connection for the third time, the variable
isolation_ is reset Connection.completeReset. If users call setTransactionIsolation and executed,
the server does not send any piggybacking update because the isolation level has not changed.
 Isolation_ remain as UNKNOWN until getTransactionIsolation is called
 or a different statement causing a change of the isolation level
 is executed.  As mention before, we should think about change this to READ_UNCOMMITTED.
With introducing getTransactionIsolationX and assertion is never reach. Therefore, no assertion.
The client driver acts as embedded as without commit action when setTransactionIsolation is
Performance concern: This fix does not improve performance, it will just move the server round-trip.
In some cases performance will be worse for the initial setTransactionIsolation call, depending
 whether isolation_ value being set to READ_COMMITTED or not. If it is, one round-trip (check
+ short-circuit). If it is not, two round-trip (check + change).

I don't fully understand piggybacking. Any suggestion is welcome.  I simply think this is
a good place to address this bug and DERBY-4343. I will suggestion to open a new JIRA for
the performance concern.

I run suits.all and derbyall. 

> With derby client setTransactionIsolation executes and commits even if isolation has
not changed 
> -------------------------------------------------------------------------------------------------
>                 Key: DERBY-4314
>                 URL: https://issues.apache.org/jira/browse/DERBY-4314
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC, Network Client
>    Affects Versions:,,,,,
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: DERBY-4314-2.diff, DERBY-4314-3.diff, DERBY-4314-5.diff, derby-4314-6a-initial_piggybacking.diff,
derby-4314-6a-initial_piggybacking.stat, DERBY-4314-6b-combinepiggybacking.diff, DERBY-4314-6c-combineaftermerge.diff,
derby-4314-6d-handle_xa.diff, DERBY-4314-7-withoutpiggybacking.diff, DERBY-4314.diff, ReproIsoLost.java,
TestConnReuse.java, utilXid.java
> With in EmbedConnection.setIsolation() we have a check to see if the isolation level
is the same and if so just return without doing a commit:
>   public void setTransactionIsolation(int level) throws SQLException {
> 		if (level == getTransactionIsolation())
> 			return;
> with org.apache.derby.client.am.Connection we have no such check. It would be good if
the client driver acted like embedded.

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

View raw message