BTM
  1. BTM
  2. BTM-5

pooling of prepared statements / statement cache

    Details

    • Type: New Feature New Feature
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Caching of PreparedStatement's could improve performance with certain databases and JDBC drivers.

        Activity

        Hide
        Ludovic Orban added a comment -

        PoolingDataSource can now cache prepared statements. A new 'preparedStatementCacheSize' property has been added which defaults to 0 so default behavior should not change.

        When set to 1 or more, PoolingDataSource will cache the x most used PreparedStatements per physical connection. When enabled, user should make sure that the database has enough resource to support potentially all cached prepared statements.

        For instance, Oracle keeps one cursor open per prepared statement. If a pool of max size 10 connections has a prepared statement cache size of 20, you must make sure the user configured in the pool can keep 200 cursors open at once.

        Note that this requires to keep the java.sql.Connection objects open for as long as XAConnections so this requires behavior equivalent to when keepConnectionOpenUntilAfter2Pc is set to true. This flag then becomes obsolete and has been removed as only this behavior is now supported. That might have a small impact on applications heavily mixing local and global transactions in regard to error mesages.

        Show
        Ludovic Orban added a comment - PoolingDataSource can now cache prepared statements. A new 'preparedStatementCacheSize' property has been added which defaults to 0 so default behavior should not change. When set to 1 or more, PoolingDataSource will cache the x most used PreparedStatements per physical connection. When enabled, user should make sure that the database has enough resource to support potentially all cached prepared statements. For instance, Oracle keeps one cursor open per prepared statement. If a pool of max size 10 connections has a prepared statement cache size of 20, you must make sure the user configured in the pool can keep 200 cursors open at once. Note that this requires to keep the java.sql.Connection objects open for as long as XAConnections so this requires behavior equivalent to when keepConnectionOpenUntilAfter2Pc is set to true. This flag then becomes obsolete and has been removed as only this behavior is now supported. That might have a small impact on applications heavily mixing local and global transactions in regard to error mesages.

          People

          • Assignee:
            Ludovic Orban
            Reporter:
            Ludovic Orban
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: