Hi Kyrre, > I saw that you had checked in a fix in SVN for the > issue I reported. The fix does not fix my problem, > however.
Hmm... :-) I believe that my latest checkings (earlier today) completely removed the finally block. The connection can be closed via the JdbcResult.release() method. Let me know if I missed something. > I believe that the finally-block should be removed > completely, and the connection closed elsewhere. It > seems to me that the pooling mechanism should keep a > lifetime of the connection (eg number of times used), > and close the connection and remove from the pool > after a certain amount of time. This raises the > question on what to do in the case when connections > aren't pooled, however. When using a connection pool, "virtual" connections are issued and when they are closed they should be transparently/internally reused. That's my understanding at least. Here is the plan that I defined with Thierry Boileau who is responsible of the refactoring of the JDBC client: - release beta 21 later today with the "connection closed" bug fixed - for 1.0 RC1, remove the dependency on Apache DBCP/Pool and rely instead on JDK's DataSource class which allow the usage of any pooling mechanism (including Apache DBCP). - for 1.0 RC1, implement the XML resultset format with an automatic release of the connection. > I'm quite busy with work at the moment, but I'll look > into setting up my environment for development against > the restlet source, so I can submit a fix rather than > just ranting on the mailing list :-) Please try to coordinate with Thierry around this issue (comment/patches/tests): http://restlet.tigris.org/issues/show_bug.cgi?id=104 > BTW, I'm using the JavaDB (derby) as the database to > test for, in case that makes any difference. Hopefully that doesn't make any. Best, Jerome
