All Versions
44
Latest Version
Avg Release Cycle
51 days
Latest Release
1608 days ago

Changelog History
Page 2

  • v19.2 Changes

    September 14, 2017
    • 🛠 Fixed a rarely occurring bug in ViburListener.getTakenConnections().
    • 🔧 Renamed one configuration option: a) defaultTransactionIsolationValue -> defaultTransactionIsolationIntValue (added Int before Value).
    • 🔨 Various other logging improvements and refactoring.

  • v19.1 Changes

    August 17, 2017
    • 🛠 Fixed a rarely occurring NPE in DefaultHook.InitConnection, introduced in version 19.0.

  • v19.0 Changes

    August 09, 2017
    • 🔄 Change the invocation of InitConnection hook to cover cases when establishing the connection was unsuccessful.
    • Adapted the new functionality introduced in Vibur Object Pool 19.0 which allows the real time waited to obtain a connection from the pool to be reported back to the GetConnection hook. Before the time reported to GetConnection hook was sometimes "polluted" by the time taken to establish new connection to the database when the pool was lazily creating such.
    • ⚡️ Javadoc updates and clarifications, various logging improvements.

  • v18.0 Changes

    June 28, 2017
    • ➕ Added getTakenConnectionsStackTraces() and getTakenConnections() to ViburDataSource interface. The taken Connection information now includes the takenNanoTime and lastAccessNanoTime, the thread that has taken the Connection and a Throwable representing the location (stack trace) at the moment when the Connection was taken. The application also has access to the taken Connection proxy and can close it forcefully if needed.
    • ✂ Removed ValidateConnection hook due to being underutilized.
    • 🔨 Various other logging improvements and refactoring.

  • v17.1 Changes

    June 23, 2017
    • 🔨 Javadoc and logging improvements; other minor fixes and refactoring.
    • Adopted changes from Vibur Object Pool 17.1.

  • v17.0 Changes

    April 05, 2017

    • Reimplemented the StatementExecution hook as an around advice (in terms of AOP) instead of being an after advice as before. Now any implemented by user StatementExecution hooks are responsible for using the supplied StatementProceedingPoint to pass the call to the intercepted Statement "execute..." method or to the next registered StatementExecution hook via something like:

      (proxy, method, args, sqlQuery, sqlQueryParams, proceed) -> { // Java 8 try { // do something before the real method execution, for example, increment a queriesInProcess counter // or start a stopwatch

          Object result = proceed.on(proxy, method, args, sqlQuery, sqlQueryParams, proceed); // execute it

    // examine a thrown SQLException if necessary, retry the Statement execution if appropriate, etc

    return result;

} finally {
    // do something after the real method execution, for example, decrement a queriesInProcess counter
    // or stop a stopwatch
}

      }

    This construct allows for easy execution of supplied by user before and after Statement execution logic.

    • 🛠 Fixed a minor bug in building sqlQueryParams.
    • 🔨 Various other small refactoring, javadoc updates and clarifications, source code clean-up.

  • v16.2 Changes

    February 10, 2017
    • 🚀 Small performance / memory consumption improvements on top of 16.1 release.
    • 🛠 Fixed a minor bug in Statement caching.
    • 🔨 Small refactoring - renamed proxy package to stproxy; javadoc updates and clarifications.

  • v16.1 Changes

    January 11, 2017
    • 🚀 Small performance improvements on top of 16.0 release.

  • v16.0 Changes

    January 09, 2017
    • 🐎 Performance improvements of the programming hooks (version 12.0 onwards) implementation.
    • 🛠 Fixed a minor bug in the implementation of logAllStackTracesOnTimeout from last release.

  • v15.0 Changes

    January 04, 2017
    • ➕ Added an sqlException param to the StatementExecution hook params.
    • ➕ Added ValidateConnection programming hook.
    • ➕ Added logAllStackTracesOnTimeout configuration option - allows in case of Connections exhaustion the application to log not only the stacktraces of the threads that are holding the currently taken Connections but also the stacktraces of all other threads in the JVM. This option is for troubleshooting purposes only as it may generate a VERY large log output.
    • Intercepted the executed SQL query string in the Connection and Statement InvocationHandlers; doesn't longer depend on the JDBC driver functionality from preparedStatement.toString().
    • 🔨 Various other refactoring and improvements.