You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2008/02/20 17:49:44 UTC
[jira] Created: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
-----------------------------------------------------------------------------------------------------------
Key: DERBY-3441
URL: https://issues.apache.org/jira/browse/DERBY-3441
Project: Derby
Issue Type: Sub-task
Components: JDBC, Network Client
Affects Versions: 10.4.0.0
Reporter: Kristian Waagan
Fix For: 10.4.0.0
Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dyre Tjeldvoll updated DERBY-3441:
----------------------------------
Derby Info: (was: [Patch Available])
I think all available patches has been committed.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-1c-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570799#action_12570799 ]
Kristian Waagan commented on DERBY-3441:
----------------------------------------
The ones you mention are not too heavy weight.
What about result sets?
When running some of the tests, I observed lock timeouts. The failing tests were all SUR tests, and I think the locking behavior might be a bit special there.
I tried a very experimental patch, where I closed the result sets on logical statement close and when running suites.All I was down to around 20+ errors/failures (as opposed to around 180).
Most of these I could link to an existing bug.
So even though I can't provide a proper answer now, I do believe there is more to be handled than what you mentioned above. I'll come back with more info as soon I as have any.
All of this is a bit in the blue currently, so feedback is very much appreciated.
I hope to get the basic machinery into place, and then work on issues one by one from there.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Fix For: 10.4.0.0
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Attachment: derby-3441-2a-minor_am_refactoring.diff
Thanks for the comment Dan. I'll address your other comments later.
'derby-3441-2a-minor_am_refactoring.diff' addresses Dans comment about the improvement in resetParameters. I changed this (and other existing code) to use Arrays.fill, and also removed some unnecessary throws clauses from the existing code. I figured out 'batch_' was never set to null, so I made it final and removed a null check.
In the future it might be better to only create the ArrayList if you actually do batching, and maybe add a clearBatchX method that will be called where batch_.clear is called currently.
Committed patch 2a to trunk with revision 631515.
Have run a subset of the regression tests, am running the full suite for verification.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Attachment: derby-3441-1b-statement_reset.diff
'derby-3441-1b-statement_reset.diff' is another try at a proper reset procedure.
The following has been changed:
a) Added JavaDoc to Statement.resetForReuse
b) Extracted "user controllable attributes" from the init method, and put them into a separate method.
These attributes must be reset when the statement is put into the cache.
Examples are query timeout, fetch direction hint and max rows to fetch.
c) The allowAutoCommit argument for willTickleServer(), is now set to connection_.autoCommit
Does anyone have any useful info on the willTickleServer method?
d) Calling batch_.clear() (ArrayList) instead of clearBatch(), to avoid catching/throwing SQLException.
See related comment for patch 2a above.
e) Removed the outer try-catch clause, and the method now throws SqlException.
Dan, I hope your comments are addressed.
Having slugged through the code, did anything come across as strange?
I.e. why is X reset, but not Y?
Patch ready for review.
I hope to commit later today, even if I don't have full confidence in the patch. It is a lot better than the current solution anyway, and I'll work on improving it. When the patch for this issue is committed, I will enable the statement pooling code by committing DERBY-3329.
The other know new defect is DERBY-3457, which has a patch awaiting review as well.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572588#action_12572588 ]
Daniel John Debrunner commented on DERBY-3441:
----------------------------------------------
I think a list of what is being reset in resetForReuse()'s javadoc (for the method) would be very useful. Otherwise one has to "slug" through the
code figuring out what is being reset.
A comment to explain this code would be really good:
+ } catch (SqlException sqle) {
+ throw sqle.getSQLException();
+ }
Ie. why is the top-level exception not being thrown.
Minor improvement in resetParameters()
+ for (int i = 0; i < parameterMetaData_.columns_; i++) {
+ parameters_[i] = null;
+ parameterSet_[i] = false;
+ parameterRegistered_[i] = false;
+ }
would be to use Arrays.fill().
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Derby Info: [Patch Available]
Assignee: Kristian Waagan
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Dyre Tjeldvoll (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dyre Tjeldvoll resolved DERBY-3441.
-----------------------------------
Resolution: Fixed
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-1c-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Attachment: derby-3441-3a-extract_setTransactionIsolationX.diff
'derby-3441-3a-extract_setTransactionIsolationX.diff' creates an internal setTransactionIsolationX method from the java.sql.Connection.setTransactionIsolation. I need to set the transaction isolation level on connection reset, and extracted the internal method to avoid checking for a closed connection multiple times. The extraction follows a typical pattern used in the client driver.
The logic remains unchanged.
Committed to trunk with revision 632279.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572904#action_12572904 ]
Kristian Waagan commented on DERBY-3441:
----------------------------------------
I have run suties.All and derbyall without failures with patch 2a, Sun JDK 1.6.0 on Solaris 10.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Attachment: derby-3441-1c-statement_reset.diff
'derby-3441-1c-statement_reset.diff' implements a working reset procedure for statement pooling.
Besides the new functionality, I also had to modify some existing code that broke statement pooling. The way things were in the existing code does not seem correct to me, but I need more time to determine what to do about it.
Also, we should probably discuss whether the required changes should go into 10.4 or be included only in the next release.
For now I've tried to disturb as little as possible. Some cleanup will be required later.
Since I'm going away for one week, it will have to wait until I'm back.
And I'm sorry for committing this patch so quickly, but all tests run cleanly and it is required for testing the statement pooling feature.
Committed patch 1c to trunk with revision 632334.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-1c-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-3441:
-----------------------------------
Attachment: derby-3441-1a-statement_reset.diff
'derby-3441-1a-statement_reset.diff' is the first draft of a reset procedure for a statement to be reused in a statement pool. There might be some room for refactoring in am.Statement, since the new method copies code from various other places.
Please review / comment.
I am not confident this is the best / correct way of doing it, but I can't see any errors caused by it either. Suggestions for how to test this is also welcome (or tests :) )!
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan closed DERBY-3441.
----------------------------------
Closing the issue.
Some cleanup has been done as part of DERBY-3581, by removing a unnecessary flag.
A comment on the code below, from Connection.completeReset(boolean,boolean):
if (closeStatementsOnClose) {
// NOTE: This is to match previous behavior.
// Investigate and check if it is really necessary.
this.isolation_ = TRANSACTION_UNKNOWN;
java.util.Set keySet = openStatements_.keySet();
for (java.util.Iterator i = keySet.iterator(); i.hasNext();) {
Object o = i.next();
((Statement) o).reset(closeStatementsOnClose);
}
} else {
// Must reset transaction isolation level if it has been changed.
if (isolation_ != Connection.TRANSACTION_READ_COMMITTED) {
// This might not fare well with connection pools, if it has
// been configured to deliver connection with a different
// isolation level, i.e. it has to set the isolation level again
// when it returns connection to client.
// TODO: Investigate optimization options.
setTransactionIsolationX(Connection.TRANSACTION_READ_COMMITTED);
}
}
I have not been able to enter the for-loop, as there aren't any open statements. They are being closed before we get this far, so I'm wondering if we could replace the for loop with an assert. Maybe this code comes from previous functionality or behavior. If 'closeStatementsOnClose' is false, it means JDBC statement caching is enabled.
After that, one would have to check if the handling of the isolation level can be merged as well, in which case the 'closeStatementsOnClose' variable can be removed.
This would have to be checked when using both ClientConnectionPoolDataSource and ClientXADataSource. My investigations so far have been focused on the connection pool data source.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.1.3
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.1.3
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-1c-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570773#action_12570773 ]
Daniel John Debrunner commented on DERBY-3441:
----------------------------------------------
What is needed for a reset beyond clearParameters, clearBatch and clearWarnings? Just wondering why these are too heavy weight?
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Fix For: 10.4.0.0
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-3441) Determine and implement a proper
procedure for resetting a prepared statement for reuse in a statement pool
Posted by "Kristian Waagan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-3441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573669#action_12573669 ]
Kristian Waagan commented on DERBY-3441:
----------------------------------------
Forgot to say, I ran derbynet._Suite and jdbcapi._Suite without failures, and I'm running the full set of regression tests to verify.
> Determine and implement a proper procedure for resetting a prepared statement for reuse in a statement pool
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3441
> URL: https://issues.apache.org/jira/browse/DERBY-3441
> Project: Derby
> Issue Type: Sub-task
> Components: JDBC, Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Fix For: 10.4.0.0
>
> Attachments: derby-3441-1a-statement_reset.diff, derby-3441-1b-statement_reset.diff, derby-3441-2a-minor_am_refactoring.diff, derby-3441-3a-extract_setTransactionIsolationX.diff
>
>
> Initial investigations indicate there are no existing suitable methods to properly reset a prepared (or callable) statement for reuse with a statement pool.
> A full reset is too heavy weight and defeats the purpose of statement pooling, but a proper procedure should be achievable by reusing existing pieces of code.
> Correctness is of course the most important thing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.