[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Derby Info: (was: [Patch Available]) Thanks for having a look at the patch Knut Anders. I committed 'derby-3324-4a-statementkey_asserts.diff' to trunk with revision 619306. This should conclude my work on this issue. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff, derby-3324-2a_argument_reordering.diff, derby-3324-3a_argument_reordering_additional.diff, derby-3324-4a-statementkey_asserts.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-2a_argument_reordering.diff 'derby-3324-2a_argument_reordering.diff' reorders the arguments of two methods in StatementKeyFactory, as per Dan's comment above. It also updates StatementKeyFactoryTest accordingly. There are no existing code using these methods yet. I consider this a simple and good change, and will commit it without further delay. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff, derby-3324-2a_argument_reordering.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-4a-statementkey_asserts.diff 'derby-3324-4a-statementkey_asserts.diff' adds asserts (SanityManager) for the various arguments in the StatementKey constructor. I'd like to get some feedback on whether the checking is appropriate, or if the patch should be discarded. Patch ready for review. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff, derby-3324-2a_argument_reordering.diff, derby-3324-3a_argument_reordering_additional.diff, derby-3324-4a-statementkey_asserts.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-3a_argument_reordering_additional.diff I forgot to reorder the arguments in one of the methods. 'derby-3324-3a_argument_reordering_additional.diff' fixes this. Committed to trunk with revision 617110. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff, derby-3324-2a_argument_reordering.diff, derby-3324-3a_argument_reordering_additional.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Derby Info: [Patch Available] JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff, derby-3324-2a_argument_reordering.diff, derby-3324-3a_argument_reordering_additional.diff, derby-3324-4a-statementkey_asserts.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1d-jdbc_statementcache.diff 'derby-3324-1d-jdbc_statementcache.diff' deprecates version 1c and contains only two changes. I removed the redundant null check Knut Anders commented on and fixed some bad formatting in the string created by StatementKey.toString. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1e-jdbc_statementcache.diff Yet another version of the patch... 'derby-3324-1e-jdbc_statementcache.diff' does not enable the tests, because the classes being tested are not pulled into the jar files. The reason for this is that they are not used by any other classes yet. Instead of doing something explicit to include the files, I will wait until they are being used. Note that the tests themselves are still in the patch. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat, derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-jdbc_statementcache.diff Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1c-jdbc_statementcache.stat derby-3324-1c-jdbc_statementcache.diff 'derby-3324-1c-jdbc_statementcache.diff' replaces revision 1b and contains the following changes: * Merged all key classes/interfaces into one class. This looks a lot simpler! Thanks for the suggestion Knut Anders. * Added some SanityManager.DEBUG blocks with asserts in JDBCStatementCache. If nulls are received, it indicates a programming error, but Derby should/will not fail. In an insane build, the worst effect will be a NPE somewhere else or that a statement that could have been cached will be thrown away and prepared again the next time. * Added a test case. * Minor tweaks to the documentation. I'm still using an IAE, and the message is not localized. However, getting a null for the compilation schema or the SQL query string suggests a programming error and should be caught before a release is produced, or handled before it gets this far in the code. Patch ready for review. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat, derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1b-jdbc_statementcache.stat derby-3324-1b-jdbc_statementcache.diff 'derby-3324-1b-jdbc_statementcache.diff' replaces version 1a. The following has been changed: 1) Removed keys for statements specifying which auto-generated columns to get, as we currently don't support this in the client driver. Handling this area will need some effort (as part of another issue), as we do support the relevant prepareStatement methods if the array specifying the columns to get is null. 2) Added a new key for CallableStatement (CallKey). 3) Renamed factory methods from newInstance to newPrepared, and introduced newCallable. 4) Renamed method in cache from insertStatement to cacheStatement. 5) Various documentation fixes/changes. 6) Chose to throw assert error if closing a statement in the cache fails. For insane builds, the exception will be ignored. I forgot to handle CallableStatement explicitly. The way this is planned now, is to use a separate key for CallableStatements and then cast the PreparedStatement that comes out of the cache; CallableStatement cs = (CallableStatement)cache.getCached(CallKey) I could add more machinery around this, for instance making sure objects inserted with a CallKey is indeed a CallableStatement, but I'm not sure if it is required for code at this level (Derby internal). I do not want to let the cache know too much about what is going on, as it's only there to hold references for objects implementing the PreparedStatement interface. I plan to commit in a few days, and I also expect there will be another patch with some more tests and the required changes for writing the tests. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat, derby-3324-1b-jdbc_statementcache.diff, derby-3324-1b-jdbc_statementcache.stat Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Derby Info: [Patch Available] JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-3324) JDBC statement cache implementation
[ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-3324: --- Attachment: derby-3324-1a-jdbc_statementcache.stat derby-3324-1a-jdbc_statementcache.diff 'derby-3324-1a-jdbc_statementcache.diff' is the first iteration of a JDBC statement cache implementation. I'm a bit short on time right now, so there won't be too much comments... Please read the comments of DERBY-3313 for the overview. I have redone the statement key hierarchy, and I would especially appreciate some feedback on the hash code generation. JDBCStatementCache, StatementKey and StatementKeyFactory are the classes that are visible outside the package. I need to write a few more tests, but thought I'd give people the chance to have a look at the code over the weekend ;) The patch will enable some tests, but none of the new code will be used by Derby yet. Patch ready for review. JDBC statement cache implementation --- Key: DERBY-3324 URL: https://issues.apache.org/jira/browse/DERBY-3324 Project: Derby Issue Type: Sub-task Components: Network Client Affects Versions: 10.4.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Priority: Minor Fix For: 10.4.0.0 Attachments: derby-3324-1a-jdbc_statementcache.diff, derby-3324-1a-jdbc_statementcache.stat Implement a cache for storing JDBC prepared statement objects. The cache will be responsible for holding free prepared statement objects that can be reused, and also to throw away objects if the cache grows too big. All objects in the cache must belong to the same physical connection, but they can be reused across logical connections obtained from a single physical connection in a connection pool. This component is probably a candidate for code sharing between the client and the embedded driver. Sharing will not be part of this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
