Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/1576
@mtaylor
> Each time a connection is released back to the pool, the prepared
statements need to be reinitialized.
I haven't understood it: do you mean in a generic pool implementation (eg
[HIkariCP](https://github.com/brettwooldridge/HikariCP)) or in the one I've
done?
> Did you look to see if reconnects are handled by the JDBC driver? I'd
expect the JDBC client libs to take care of reconnects after a drop, meaning we
don't have to think about this at the application level.
Yes and in the [JDBC 4.1
spec](https://www.google.it/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjmj9vss_fWAhUSaFAKHc67D90QFggnMAA&url=http%3A%2F%2Fdownload.oracle.com%2Fotn-pub%2Fjcp%2Fjdbc-4_1-mrel-eval-spec%2Fjdbc4.1-fr-spec.pdf&usg=AOvVaw0pEUpMaXVVBk19KJsXuaaU)
there is no mention about it. I suspect this is the reason why are provided
operations on the Connection as setNetworkTimeout and isValid: in order to have
a platform indipendent way to manage reconnection/failures management on
application level.
> We may at some point in the future want to manage our own connection
pool. SQLFileFactory would benefit from this. At the journal level, we would
need to refactor to sync at the operational context level. I'm not against
using the Connection Pool to handle the optmistic lock, as it doesn't affect
perf.
Agree!
---
