[
https://issues.apache.org/jira/browse/DERBY-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-6066:
-----------------------------------
Attachment: SampleProgram.java
Hi Knut, thank you for reviewing the patch. I tried two different combinations
of network server and client
1)10.3 server and trunk client
2)trunk server and trunk client
I put println in my patch in 3 places inside
o.a.d.client.am.Connection:getTransactionIsolationX(),
1)one just at the very beginning of the method,
System.out.println("in top code");
2)one right after following if statement
if (isolation_ != TRANSACTION_UNKNOWN) {
if (SanityManager.DEBUG) {
SanityManager.ASSERT(supportsSessionDataCaching(),
"Cannot return cached isolation when caching is " +
"not supported!");
}
return isolation_;
}
System.out.println("outside if stmt");
3)and the last one inside the following if code
if (getTransactionIsolationPrepStmt == null ||
!(getTransactionIsolationPrepStmt.openOnClient_ &&
getTransactionIsolationPrepStmt.openOnServer_)) {
System.out.println("inside if stmt");
I ran the attached SampleProgram with both these configurations and like you
said, in case of 10.3 server and trunk client, I see all the 3 printlns getting
printed. But for trunk server and trunk client, only the println "in top code"
gets printed.
So the code in question is definitely getting used for working with the older
versions of servers that do not have support for isolation level caching.
Additionally, I looked at DERBY-4314 and a good writeup on piggybacking at
http://wiki.apache.org/db-derby/Derby3192Writeup and the comments in these 2
places seem to indicate that there might be cases, where Newtwork Servers(ones
with support for isolation level caching) have not had a chance to send the
isolation level piggybacked as part of some other communication between client
and server and hence the call to getTransactionIsolation on client side will
actually end up making to the server because isolation level on the client side
will still be set to TRANSACTION_UNKNOWN. I have not been able to create a test
case for such a scenario but just wanted to point out that the code in question
in getTransactionIsolationX might also be getting used for such a scenario.
I will put some additional comments in my 2nd patch about where the code in
question is getting used so it will be easier to understand the code in future.
Also, I was wondering if we have a junit test for testing compatibility between
different version of Network Server and client. If so, I will like to add a
simple junit test for 10.3 Network Server and higher revision of client.
> Client should use a prepared statement rather than regular statement for
> Connection.getTransactionIsolation
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6066
> URL: https://issues.apache.org/jira/browse/DERBY-6066
> Project: Derby
> Issue Type: Improvement
> Components: Network Client
> Reporter: Mamta A. Satoor
> Assignee: Mamta A. Satoor
> Attachments: DERBY6066_patch1_diff.txt, DERBY6066_patch2_diff.txt,
> SampleProgram.java
>
>
> This jira is similar to DERBY-6053 but for
> o.a.d.client.am.Connection.getTransactionIsolation. Use prepared statement
> rather than regular statement every time user makes a get transaction
> isolation call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
