2014-05-06 8:45 GMT+02:00 Lukas Eder <[email protected]>: > Hi Stan, > > 2014-05-06 8:04 GMT+02:00 Stanislas Nanchen <[email protected]>: > > Hi everyone, >> >> We had encountered a problem with batch operations that would eat up our >> Connection Pool. >> >> When a query is prepared for batch operation, it is, in a first step, >> almost executed by Jooq >> only to be stopped by a QueryCollectorSignal exception. The goal of this >> first step is to generated the SQL text (in >> a second phase, the sql is bound to all records for batch operation). >> >> However it seems that the connection opened in the first step is not >> correctly closed after the >> QueryCollectorSignal. >> > > Thanks for the heads-up with your analysis. > > >> That's an interesting issue. I wonder if other exceptions (e.g. > constraint violations originating from the DB) might be able to produce the > same issue. > I have registered an issue for this and will investigate soon: > https://github.com/jOOQ/jOOQ/issues/3234 > > jOOQ's integration tests count the "open" / "close" ratio across all > tests. Interestingly, this case must have slipped by this check. >
The reason for this is that only the ExecuteListener lifecycle is currently monitored, not the ConnectionProvider lifecycle. I can reproduce your issue easily. Thanks for reporting! > > As we use a Connection Pool, problems can be avoided by always "touching" >> the connection >> (open/close) after the transaction is started. The Connection Pool will >> then serve "proxies" to >> the subsequent 'openConnection' calls and it is no more critical if one >> of those is not correctly >> closed. (We have this workaround in place). >> > > Yes, containers usually do the same to prevent resource leak bugs. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
