Hi Lukas, > Does Wicket not manage your connections via DataSources, like a J2EE > container? Then you shouldn't need to worry about connections > yourself... J2EE containers usually have a shared connection pool for > these purposes, but I don't know Wicket.
Wicket doesn't do anything with databases, but i do use Glassfish connection pooling. However, as far as i'm aware, i still need to "close" pooled connections to return them to the pool. Please correct me if i'm wrong! > I'm sorry I forgot about that. I'll add a 1.6.0-SNAPSHOT version soon, > implementing this. I prefer attaching (if possible) at deserialisation > time, because some advanced data types (especially with Oracle) need > an open connection to be constructed. But there shouldn't be any > drawback in handling the other case, too. > > https://sourceforge.net/apps/trac/jooq/ticket/535 Thanks. Could you also test whether the JDBC connection is still connected and call provideFor() when the connection isn't? In the current situation, i'm closing the (pooled) JDBC connection without serializing/detaching any jOOQ objects at the end of the HTTP request cycle. > Thank you for mentioning this. I keep forgetting about Netbeans. It > seems that Eclipse, Netbeans and Maven don't have exactly the same > compiler behaviour when overloaded generic methods are involved, when > <T> binds to Object. This is a rather complex topic. > > In the mean time, you could try with Eclipse...? I will try that, thanks! Sander
