Just adding something in top of that:

The application server will probably cache prepareCall and prepareStatement. So, I think we will need to measure prepares in separate.
This will provide information to users if they need to increase preparedStatementCache or not.

Say... if a method is spending too much time preparing statements (and caling too many prepare statements) that means the user needs to increase prepared statement cache, or change his code.

As for queries, we need to define what we want to measure. We could measure:

- Time used to prepare Statement (we really need this, so this could give users information if they need to increase their statement's cache)
- Time used to execute the query
- Time used to navigate the query.

I really like the idea of measuring the navigation of the query, but then here it's going to be difficult (I guess) to guess if the user is closing the statement properly, and how to treat nested calls.

We will be nesting invocations. Say if you have this code:

public void methodA() throws SQLException
{
 Rset rset = preparedStatement.executeQuery();

 while (rset.next())
 {
 anotherEJB.invokeMethod(rset.getString(1));
 }

 rset.close();
}

for 1) As we will be nesting calls... we need to have the close called before exiting the method. Trusing on finalize could mean the method is poping the stack of methods before the query.

Then what we can do is... if the method closes (pop) before the query.close().
we will do a pop again, and probably set an error on the node (query) saying that a rset.close() wasn't called.


Clebert

for 2) Lets do it... I liked the idea also!