[
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.
