Great. I added my "patch" as a comment [1] (seemed easier than producing an actual .patch file, but if you need it I can also make you that).
[1] https://issues.apache.org/jira/browse/DBCP-426?focusedCommentId=14152285&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14152285 2014-09-29 22:01 GMT+02:00 Phil Steitz <phil.ste...@gmail.com>: > On 9/29/14 2:55 AM, Kasper Sørensen wrote: > > OK thank you for your replies. I will suggest in the Apache MetaModel dev > > mailing list to do it in that layer instead then. > > > > On that subject ... do you know of a way for us to mark a connection > > invalid? I don't see any methods on BasicDataSource to do that - is > there a > > way that you know of? > > There is no simple way to do this, unfortunately. I just opened > DBCP-426 to track this. Patches welcome. > > Phil > > > > 2014-09-25 3:04 GMT+02:00 Bernd Eckenfels <e...@zusammenkunft.net>: > > > >> 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 > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
