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
