Re: Removing our datasource/pooling implementation.
От | Oliver Jowett |
---|---|
Тема | Re: Removing our datasource/pooling implementation. |
Дата | |
Msg-id | 41E464C4.6060904@opencloud.com обсуждение исходный текст |
Ответ на | Re: Removing our datasource/pooling implementation. (Kris Jurka <books@ejurka.com>) |
Ответы |
Re: Removing our datasource/pooling implementation.
|
Список | pgsql-jdbc |
Kris Jurka wrote: > First I don't use our PooledConnection and I'm also a little unclear on > whose resposibility (CPDS vs the actual pool) certain things are, so this > is just a combination of anecdotes and looking at the code. Nothing is > really broken for normal use, but when something goes wrong there is very > little error detection and fallback. Specifically when a connection to > the database server is lost via a server restart or even potentially user > level code Statement.execute("SET client_encoding TO 'LATIN1'); the dead > connection is not destroyed and will keep being given to clients. The CPDS/PooledConnection has the responsibility for creating connection proxy objects and reporting proxy connection closes and connection fatal errors via a connection listener. The actual pool is responsible for things like pool size, max idle time, whether to recheck connections periodically, etc. Looking at the code, it looks like fireConnectionFatalError() isn't being called in the normal execution (non-setup) path at all. If it was being called, then connection pools would have a chance to see the error via a connection listener and discard the bad connection. I will look at fixing this. Probably the best way to do it is monitor the SQLState of thrown exceptions in the InvocationHandler and know about which states are fatal (e.g. connection failure, driver internal errors). -O
В списке pgsql-jdbc по дате отправления: