dependabot[bot] opened a new pull request, #19496:
URL: https://github.com/apache/pinot/pull/19496

   Bumps [com.mchange:c3p0](https://github.com/swaldman/c3p0) from 0.14.1 to 
0.14.2.
   <details>
   <summary>Changelog</summary>
   <p><em>Sourced from <a 
href="https://github.com/swaldman/c3p0/blob/v0.14.2/CHANGELOG";>com.mchange:c3p0's
 changelog</a>.</em></p>
   <blockquote>
   <p>c3p0-0.14.2
   -- Guard against the possibility of &quot;dueling Statement caches&quot;, 
where the Statement
   cache, when it goes to a Connection intending to prepare a new 
PreparedStatement,
   instead receives a reference to a Statement in a different cache, which our 
Statement
   cache may have already encountered, and so cached itself! Insidiously, such 
references
   might be re-cached under different keys than when we first encountered and 
cached them.
   We key on a variety of characteristics beyond the Statement's SQL text, 
including
   result_set_type, result_set_concurrency, autogeneratedKeys, and 
resultSetHoldability.
   These characteristics are immutable to us, but JDBC-driver-based caches may 
have access
   to PreparedStatement internals, and may simply mutate these properties prior 
to client
   checkout (or, less charitably, ignore them), and so return a reference we 
have already
   seen and cached under one key, but would now be cached under a distinct key! 
We do not
   want to track Statements whose putatively fixed properties may be evolving 
unbeknownst
   to our cache, and in fact, we presume that we receive fresh Statements 
whenever we ask
   a Connection to prepare a Statement. Dueling Statement caches constitute a 
pathological
   condition from our perspective. But it's a condition that does seem to occur 
in the wild,
   so we need to be resilient to it! When acquiring a new Statement from a 
Connection, we
   now check whether the Statement we receive is already in the cache. If it 
is, we do not
   recachethe new Statement, and we drop the Statement from the cache. It 
becomes from our
   perspective an uncached Statement (and per the fix just below, is marked for 
clean-up
   on checkin of its parent Connection). Thanks to Devil2-O on github for 
observing and
   reporting the failures that led us to diagnose this condition.
   -- Fix a potential Statement leak when (1) a Statement cache is full, and so 
a newly
   requested PreparedStatement is returned as an uncached &quot;overload 
Statement&quot;; and
   (2) the client omits to call close() on the Statement explicitly. In this 
case,
   the Statement ended up neither under the management (and subject to eventual 
closure)
   by the Statement cache, nor marked as an uncachedActiveStatement in 
NewPooledConnection,
   which would have subjected it to automatic closure on check-in. In short, 
nothing would
   ever close() such a Statement unless and until the physical Connection 
behind it was
   eventually retired and culled from the Connection pool. (On 
Connection.close() the
   JDBC driver would clean up any unclosed Statements against the Connection.) 
We now
   capture such &quot;overload Statements&quot; as uncachedActiveStatement, so 
they do get close()ed
   as soon as the Connection is checked in.
   -- Let &quot;Claude&quot; build a stress-testing harness (complete with 
instrumenting mock JDBC
   driver) to help track down rare Statement cache faults and inconsistencies.
   c3p0-0.14.1
   -- Modify c3p0 to use new BeanInfoGen functionality, restoring compatability 
with
   Java [7,11).
   -- Modify BeanInfoGen to (optionally but by default) cache descriptors 
rather than
   regenerating for each call to an introspection method.
   -- Modify BeanInfoGen to log items skipped from descriptors due to API 
incompatibility.
   -- Modify BeanInfoGen to generate BeanInfo classes in which 
properties/events/methods that
   existed in the JVM under which they were generated and built, but do not 
exist under the
   runtime JVM are tolerate, simply omitted at runtime from BeanInfo 
descriptors. This fixes
   compatability with Java environments before Java 11, under whose API c3p0 and
   mchange-commons-java are currently built. (Thanks to Vlad Skarzhevskyy, <a 
href="https://github.com/skarzhevskyy";><code>@​skarzhevskyy</code></a> on
   GitHub, for calling attention to this issue.)
   c3p0-0.14.0
   -- Update to mill 1.1.6 and fix broken support for reproducible builds via 
the SOURCE_DATE_EPOCH
   environment variable.</p>
   <!-- raw HTML omitted -->
   </blockquote>
   <p>... (truncated)</p>
   </details>
   <details>
   <summary>Commits</summary>
   <ul>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/e52c2102f4785772a5943dc97e055f11ebe75887";><code>e52c210</code></a>
 Fix a javadoc error that broke test.docJar.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/b63f0de8c6ce4092a088bdde5bba8374e9af9e93";><code>b63f0de</code></a>
 Add release notes for c3p0 0.14.2</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/47fa7dc4bc415f770c91d464001c766435382487";><code>47fa7dc</code></a>
 Bump version for 0.14.2 final.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/42eb6a95410443ab46c510dca5c33beda6264281";><code>42eb6a9</code></a>
 Exercise the duplicate-Statement guard against all three cache 
implementations.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/56549dbc82930450ca4efe1c0647607b4d47cbe0";><code>56549db</code></a>
 Bump version to 0.14.2-SNAPSHOT.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/af82f7b7e023ba7f116c6775289d2959e564d855";><code>af82f7b</code></a>
 Update and cap CHANGELOG for 0.14.2</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/ad920456ae6dd9f8a3a1a6ac6c908d6e13fab7a7";><code>ad92045</code></a>
 Test that a driver reissuing Statements cannot poison the cache.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/1f283652813cb1adcdf136560a1be5828282ebdb";><code>1f28365</code></a>
 Update CHANGELOG with fixes toward 0.14.2.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/d64e6a2bdca867433755e913b42b4dfe8b8dca0d";><code>d64e6a2</code></a>
 Log the duplicate-Statement stack trace only at FINE.</li>
   <li><a 
href="https://github.com/swaldman/c3p0/commit/3e90a6f452eda506d0d38dfe4c3dab8b38af5e43";><code>3e90a6f</code></a>
 Sweep up Statements the cache declines to keep, so they cannot leak.</li>
   <li>Additional commits viewable in <a 
href="https://github.com/swaldman/c3p0/compare/v0.14.1...v0.14.2";>compare 
view</a></li>
   </ul>
   </details>
   <br />
   
   
   [![Dependabot compatibility 
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=com.mchange:c3p0&package-manager=maven&previous-version=0.14.1&new-version=0.14.2)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
   
   Dependabot will resolve any conflicts with this PR as long as you don't 
alter it yourself. You can also trigger a rebase manually by commenting 
`@dependabot rebase`.
   
   [//]: # (dependabot-automerge-start)
   [//]: # (dependabot-automerge-end)
   
   ---
   
   <details>
   <summary>Dependabot commands and options</summary>
   <br />
   
   You can trigger Dependabot actions by commenting on this PR:
   - `@dependabot rebase` will rebase this PR
   - `@dependabot recreate` will recreate this PR, overwriting any edits that 
have been made to it
   - `@dependabot show <dependency name> ignore conditions` will show all of 
the ignore conditions of the specified dependency
   - `@dependabot ignore this major version` will close this PR and stop 
Dependabot creating any more for this major version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this minor version` will close this PR and stop 
Dependabot creating any more for this minor version (unless you reopen the PR 
or upgrade to it yourself)
   - `@dependabot ignore this dependency` will close this PR and stop 
Dependabot creating any more for this dependency (unless you reopen the PR or 
upgrade to it yourself)
   
   
   </details>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to