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
called.
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
on
 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: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.1.1, 10.6.1.0
>            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.


Mime
View raw message