commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kasper Sørensen <i.am.kasper.soren...@gmail.com>
Subject Re: A reactive way to deal with stale connections
Date Mon, 29 Sep 2014 09:55:21 GMT
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?

2014-09-25 3:04 GMT+02:00 Bernd Eckenfels <ecki@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_san@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.sorensen@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message