db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4314) With derby client setTransactionIsolation executes and commits even if isolation has not changed
Date Mon, 27 Jul 2009 09:17:14 GMT

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

Kristian Waagan commented on DERBY-4314:
----------------------------------------

I found some useful information about the piggybacking here: http://wiki.apache.org/db-derby/Derby3192Writeup
Thank you, Dyre!

Kathey wrote:
-----
It seems that _isolation is set to TRANSACTION_UNKNOWN for new connections. This means we
will always make an extra round trip for the first setTransactionIsolation call on a connection.
Can we initialize _isolation to READ_COMMITTED when session data caching is supported instead
since that is the default for new connections?
-----
I'm slightly skeptical about this suggested change:
 1) It seems we have had bugs regarding assumptions about and caching of the isolation level
earlier.
 2) What happens if we in the future add the option to configure the default isolation level
on the server?
    It seems I have already introduced an assumption in the client code that may break (hard-coded
assumption that the default level is RC, limited to pooled/XA connections - see Connection.completeReset).
 3) This happens once for each connection if setTransactionIsolation is called before any
other round trip to the server, assuming session state caching is available. Shouldn't applications
creating loads of connections use a connection pool?

It seems to me that the client should be informed about the default isolation level as part
of the connection initialization sequence. The default value could be stored, and used later
on connection resets etc. I don't know if the DRDA specification allows this somehow. One
solution could be the product specific code points.


The latest patch looks good to me. Nitpicks:
 - mixed tabs/spaces indentation at @@ -909,6 +909,9 @@

 - mixed tabs/spaces indentation at @@ -1005,8 +1008,21 @@

 - traceExit is used instead of traceEntry. Is this intended?
    (I see this is also done in some other places in the client code)

> 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.0.0
>            Reporter: Kathey Marsden
>            Priority: Minor
>         Attachments: DERBY-4314-2.diff, DERBY-4314-3.diff, DERBY-4314.diff
>
>
> 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