Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <705249334.1140215190417.JavaMail.jira@ajax.apache.org>
Date: Fri, 17 Feb 2006 23:26:30 +0100 (CET)
From: "Kathey Marsden (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-210) Network Server will leak prepared
 statements if not explicitly closed by the user until the connection is
 closed
In-Reply-To: <1527603664.1113181887106.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12366856 ] 

Kathey Marsden commented on DERBY-210:
--------------------------------------

Firstly Deepa, let me say I am sorry I did not get to look at this part of the big patch when it was first posted.
I think I need a little more background on the two lists in questions before I can review.
Connection.openStatements_ and Connection.CommitAndRollbackListeners_

Why are they needed?

If they are needed....
What are they used for?
What is added and when?
What is removed and when (finalize/close/some other time)

The descriptions of both lists seem to describe things that I question.
The statements do not need to be  reprepared on the server after commit/rollback.
I also don't understand why the resultset would be unpositioned.


//DERBY prepared statements must be re-prepared after a commit
    // then we must traverse this list after a commit and notify statements
    // that they are now in an un-prepared state.
    final java.util.LinkedList openStatements_ = new java.util.LinkedList();

    // Some statuses of DERBY objects may be invalid on server
    // after both commit and rollback. For example,
    // (1) prepared statements need to be re-prepared
    //     after both commit and rollback                             
    // (2) result set will be unpositioned on server after both commit and rollback.
    // If they depend on both commit and rollback, they need to get on CommitAndRollbackListeners_.
final java.util.LinkedList CommitAndRollbackListeners_ = new java.util.LinkedList();


> Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
> ----------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-210
>          URL: http://issues.apache.org/jira/browse/DERBY-210
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Reporter: Kathey Marsden
>     Assignee: Deepa Remesh
>  Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png, derby-210-patch1.diff, derby-210-patch2.diff, derby-210-patch2.status, derby-210-patch3.diff, derby-210-patch4-v2.diff, derby-210-patch4-v2.status, derby-210-v2-draft.diff, derby-210-v2-draft.status, derbyStress.java
>
> Network server will not garbage collect prepared statements that are not explicitly closed by the user.  So  a loop like this will leak.
> ...
> PreparedStatement ps;
>  for (int i = 0 ; i  < numPs; i++)
> 	{
> 	 ps = conn.prepareStatement(selTabSql);
> 	 rs =ps.executeQuery();
> 	 while (rs.next())
> 	{
> 	    rs.getString(1);
> 	}
> 	rs.close();
> 	// I'm a sloppy java programmer
> 	//ps.close();
> 	}
> 			
> To reproduce run the attached program 
> java derbyStress
> Both client and server will grow until the connection is closed.
>  
> It is likely that the fix for this will have to be in the client.  The client does not send protocol to close the prepared statement, but rather reuses the PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been closed. This is how the server knows to close the old statement and create a new one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira