Hello, Replaying statements is hard as You also have to keep session context, understand various error categories and in case of modifying statements, You also need to hook into transaction Management to make it fast, reliable and cobsistent.
The JDBC drivers of Oracle together with its universal cinnection pool allow to retry select statements (TAF failover type select) as well as more recently midifying statements with the help of the transaction guard feature (http://docs.oracle.com/database/121/JJDBC/transactionguard.htm). For an ORM or Persistence Layer it might be a bit easier than for a low Level connection pool. on the other hand i always wished for jdbc pools with no fixed direct relation between logical and managed connection objects. -- http://bernd.eckenfels.net ----- Ursprüngliche Nachricht ----- Von: "woon_san" <woon_...@yahoo.com.INVALID> Gesendet: 25.09.2014 01:38 An: "Commons Developers List" <dev@commons.apache.org> Betreff: RE: A reactive way to deal with stale connections Hi Kasper, It's an interesting feature, but I don't think that should belong to commons-dbcp. Commons-dbcp module provides lower level JDBC api such as DataSource and Connection, whereas your use case seems to be proper with a higer level data access module. You might want to take a look at that kind of higher level modules like spring framework jdbc template: - http://docs.spring.io/spring-framework/docs/current/spring-framework-reference/html/jdbc.html , which provides similar features such as transaction management for instance and extensibility. Probably there are orher data access libraries like this as well. Regards, Woonsan (Sent via my mobile device. Apologies for any typos.) <div>-------- Original message --------</div><div>From: Kasper Sørensen <i.am.kasper.soren...@gmail.com> </div><div>Date:09/24/2014 13:44 (GMT-05:00) </div><div>To: dev@commons.apache.org </div><div>Subject: A reactive way to deal with stale connections </div><div> </div>Hi, In many projects I have been working on we're using commons-dbcp, and in particular the BasicDataSource. A common set-up there is to use "testOnBorrow" and a validation query to ensure that borrowed JDBC connections are working when we get them. The downside of this approach is that it's pretty heavy-weight to have to test each borrowed connection when there's a high load on the system. So I wanted to bounce an idea I have for improving the way we validate connections. Maybe it can even become a contribution to commons-dbcp, or maybe it's a application-specific improvement. My idea is inspired by the "let it crash" (and retry) way of thinking. Every time a connection would throw an exception, we would retry the latest command. As such, each querying or updation operation would thus be wrapped in a command, so that there's a central executor object that would manage the retry mechanism etc. Here's a small example: ------- Command c = new Command() { public void doWithConnection(Connection c) { // do some querying or some updation stuff with the connection } } CommandExecutor executor = new CommandExecutor(dataSource); executor.execute(c); ------- We see issues with the connections very rarely, but we need to be able to overcome it. I think this approach would archieve that. It could even ensure that a transaction is created before executing the command, and committed after the command. That way a failing command would not leave behind side-effects. Or do you guys see reasons why this would not work properly? Would it make sense to put into commons-dbcp you think? (I am working also on Apache MetaModel (incubating) and would consider doing it there, if you don't think it's good for commons-dbcp). Best regards, Kasper Sørensen
