db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-6066) Client should use a prepared statement rather than regular statement for Connection.getTransactionIsolation
Date Fri, 22 Feb 2013 16:34:15 GMT

     [ 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

Mime
View raw message