[jira] [Updated] (DERBY-6066) Client should use a prepared statement rather than regular statement for Connection.getTransactionIsolation

["Mamta A. Satoor (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mamta A. Satoor updated DERBY-6066:
-----------------------------------

    Attachment: DERBY6066_patch1_diff.txt

The attached patch has the changes to use PreparedStatement rather than Statement to get the transaction isolation level.

This is similar to what we did for set tranaction isolation level as part of DERBY-6053. 

But I noticed that my changes do not get run (I put a System.out.println inside the changes to see if it got printed when running derbyall and junit suite and the println never got printed) when I ask for get transaction isolation level or when I run the derbyall and junit suite. I found that this is because of the checkin that went in as part of DERBY-2084 which gets the current isolation level piggy backed as part of some other communication happening between cient and server and because of that get transaction isolation call on the client side does not need to go over the line to the server to find the current isolation. Copying below the piece of code(from o.a.d.client.am.Connection.getTransactionIsolationX) where we take advantage of isolation level picked from piggbacking 
            if (isolation_ != TRANSACTION_UNKNOWN) {
                if (SanityManager.DEBUG) {
                    SanityManager.ASSERT(supportsSessionDataCaching(),
                            "Cannot return cached isolation when caching is " +
                            "not supported!");
                }
                return isolation_;
            }

Just for testing my code changes, I commented out the code above(this will require us to send get isolation level on the wire to the server everytime client asks for it) and added the println in my changes and ran the tests again and I see that we spit out the println when get transaction isolation level is requested by the user. This verifies that my changes are working fine. The attached patch obviosuly doesn't have the println and it does not comment out the piggybacking isolation level usage
            if (getTransactionIsolationPrepStmt == null  || 
                    !getTransactionIsolationPrepStmt.openOnClient_) {
            	System.out.println("came in new code");
            	getTransactionIsolationPrepStmt =
                        prepareStatementX(
                                "VALUES CURRENT ISOLATION",
                                java.sql.ResultSet.TYPE_FORWARD_ONLY,
                                java.sql.ResultSet.CONCUR_READ_ONLY,
                                holdability(),
                                java.sql.Statement.NO_GENERATED_KEYS,
                                null, null);
            }

So the usage of prepared statement rather than statement for get transaction isolation will not improve the performance by a lot since we do not send these calls on the wire so much but I think it is still a good change. If there are no objections to this change, I will go ahead and commit it in couple days

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