[
https://issues.apache.org/jira/browse/DERBY-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13567952#comment-13567952
]
Kathey Marsden commented on DERBY-6053:
---------------------------------------
Thank you Mamta for looking at this,
I do not think that comment is true about statements not staying prepared
across commits.
If I prepare a statement and execute it twice with a commit in between from
client, I do not see a reprepare in the derby.log . I think maybe the
openOnServer_ property may be a relic of some place or time in the original
code base when that was true.
Thu Jan 31 10:52:46 PST 2013 Thread[DRDAConnThread_2,5,derby.daemons] (XID =
172), (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
.-4398045151445635921{2}), End compiling prepared statement: INSERT INTO T
VALUES(?,?) :End prepared statement
Thu Jan 31 10:52:46 PST 2013 Thread[DRDAConnThread_2,5,derby.daemons] (XID =
172), (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
.-4398045151445635921{2}), Executing prepared statement: INSERT INTO T
VALUES(?,?) :End prepared statement with 2 parameters begin parameter #1: 1
:end parameter begin parameter #2: CLOB(5) :end parameter
Thu Jan 31 10:52:46 PST 2013 Thread[DRDAConnThread_2,5,derby.daemons] (XID =
172), (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
.-4398045151445635921{2}), Committing
Thu Jan 31 10:52:46 PST 2013 Thread[DRDAConnThread_2,5,derby.daemons] (XID =
174), (SESSIONID = 1), (DATABASE = wombat), (DRDAID =
.-4398045151445635921{2}), Executing prepared statement: INSERT INTO T
VALUES(?,?) :End prepared statement with 2 parameters begin parameter #1: 2
:end parameter begin parameter #2: CLOB(7) :end parameter <=== Just execute
again after commit.
At least in this case, I think it can be removed from the condition. It would
be good to file an issue to investigate the openOnServer field in general.
One aside comment on this change is that for our prepared statements it might
be nice to have a HashTable keyed on the DERBY_TRANSACTION_... values instead
of separate fields for each one and repeat code.
> Client should use a prepared statement rather than regular statement for
> Connection.setTransactionIsolation
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6053
> URL: https://issues.apache.org/jira/browse/DERBY-6053
> Project: Derby
> Issue Type: Improvement
> Components: Network Client
> Reporter: Kathey Marsden
>
> o.a.d.client.am.Connection setTransactionIsolation() uses a Statement which
> it builds up each time for setTransactionIsolation() is called.
> private Statement setTransactionIsolationStmt = null;
> ...
> setTransactionIsolationStmt =
> createStatementX(java.sql.ResultSet.TYPE_FORWARD_ONLY,
> java.sql.ResultSet.CONCUR_READ_ONLY,
> holdability());
> ....
> private void setTransactionIsolationX(int level)
> ...
> setTransactionIsolationStmt.executeUpdate(
> "SET CURRENT ISOLATION = " + levelString);
> It would be better for performance and also for avoid possible garbage
> collection issues, to have a single prepared statement with a parameter
> marker.
> The program below shows repeated calls to setTransactionIsolation.
> import java.sql.*;
> import java.net.*;
> import java.io.*;
> import org.apache.derby.drda.NetworkServerControl;
> /**
> * Client template starts its own NetworkServer and runs some SQL against it.
> * The SQL or JDBC API calls can be modified to reproduce issues
> *
> */public class SetTransactionIsolation {
> public static Statement s;
>
> public static void main(String[] args) throws Exception {
> try {
> // Load the driver. Not needed for network server.
>
> Class.forName("org.apache.derby.jdbc.ClientDriver");
> // Start Network Server
> startNetworkServer();
> // If connecting to a customer database. Change the URL
> Connection conn = DriverManager
>
> .getConnection("jdbc:derby://localhost:1527/wombat;create=true");
> // clean up from a previous run
> s = conn.createStatement();
> try {
> s.executeUpdate("DROP TABLE T");
> } catch (SQLException se) {
> if (!se.getSQLState().equals("42Y55"))
> throw se;
> }
> for (int i = 0; i < 50000; i++) {
>
> conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
>
> conn.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
> }
>
> // rs.close();
> // ps.close();
> runtimeInfo();
> conn.close();
> // Shutdown the server
> shutdownServer();
> } catch (SQLException se) {
> while (se != null) {
> System.out.println("SQLState=" + se.getSQLState()
> + se.getMessage());
> se.printStackTrace();
> se = se.getNextException();
> }
> }
> }
>
> /**
> * starts the Network server
> *
> */
> public static void startNetworkServer() throws SQLException {
> Exception failException = null;
> try {
>
> NetworkServerControl networkServer = new NetworkServerControl(
> InetAddress.getByName("localhost"), 1527);
>
> networkServer.start(new PrintWriter(System.out));
>
> // Wait for the network server to start
> boolean started = false;
> int retries = 10; // Max retries = max seconds to wait
>
> while (!started && retries > 0) {
> try {
> // Sleep 1 second and then ping the network server
> Thread.sleep(1000);
> networkServer.ping();
>
> // If ping does not throw an exception the server has
> // started
> started = true;
> } catch (Exception e) {
> retries--;
> failException = e;
> }
>
> }
>
> // Check if we got a reply on ping
> if (!started) {
> throw failException;
> }
> } catch (Exception e) {
> SQLException se = new SQLException("Error starting network
> server");
> se.initCause(failException);
> throw se;
> }
> }
>
> public static void shutdownServer() throws Exception {
> NetworkServerControl networkServer = new NetworkServerControl(
> InetAddress.getByName("localhost"), 1527);
> networkServer.shutdown();
> }
>
> public static void runtimeInfo() throws Exception {
> NetworkServerControl networkServer = new NetworkServerControl(
> InetAddress.getByName("localhost"), 1527);
> System.out.println(networkServer.getRuntimeInfo());
> }
>
> }
--
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