Kris,
AFAIR, the jdbccts requires a data source, not sure about the pooling
implementation.
Hibernate has a sub-standard pooling implementation and explicitely logs
this fact when it starts up.
I'm of two minds here, if we tell people that it isn't intended for
production, AND they actually read it, we could leave it in.
On the other hand if it really doesn't work and isn't necessary then it
is just extra code we need to maintain.
+1 for removal of the pooling implementation if it isn't required for
jdbccts.
Dave
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@postgresql.org so that your
> message can get through to the mailing list cleanly
>
>
>
>
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561