From: | Aaron Mulder <ammulder(at)alumni(dot)princeton(dot)edu> |
---|---|
To: | PostgreSQL JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Removing our datasource/pooling implementation. |
Date: | 2005-01-06 19:21:39 |
Message-ID: | Pine.LNX.4.58.0501061419560.14130@saturn.opentools.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
The DataSource implementation was never meant to be robust, and
can be scrapped as far as I'm concerned. The ConnectionPoolDataSource
implementation should be kept, though it's probably not too popular since
it seems no one much uses that interface.
Aaron
On Wed, 5 Jan 2005, Kris Jurka wrote:
> Having received another report[1] of the lack of robustness of our pooling
> implementation I think we should scrap our datasource and pooling
> implementation. I previously advocated keeping it around because it
> "basically worked" and didn't really cost us anything to keep it. Now
> we're aware that it doesn't really work and I for one don't want to spend
> time fixing it when there are better options out there.
>
> I spent some time today testing jakarta's dbcp[2] and I couldn't find
> anything our code does that it cannot and there are plenty of additional
> features. Dynamic pool sizing, removing broken connections, and even
> statement pooling are available. I was impressed.
>
> Would anyone like to make a case for keeping our implementation around?
>
> Kris Jurka
>
> [1] http://gborg.postgresql.org/project/pgjdbc/bugs/bugupdate.php?1109
> [2] http://jakarta.apache.org/commons/dbcp/
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>
From | Date | Subject | |
---|---|---|---|
Next Message | Barry Lind | 2005-01-06 20:15:44 | Re: Removing our datasource/pooling implementation. |
Previous Message | Keith Hankin | 2005-01-06 18:17:29 | One byte integer support |