Re: JDBC gripe list
От | Vitalii Tymchyshyn |
---|---|
Тема | Re: JDBC gripe list |
Дата | |
Msg-id | 4D919A02.60607@gmail.com обсуждение исходный текст |
Ответ на | Re: JDBC gripe list (Craig Ringer <craig@postnewspapers.com.au>) |
Ответы |
Re: JDBC gripe list
Re: JDBC gripe list |
Список | pgsql-jdbc |
29.03.11 05:18, Craig Ringer написав(ла): > On 03/27/2011 11:14 PM, Dave Cramer wrote: >> Adding to the list is statement timeout. I seem to recall the issue is >> we do not want to spawn a thread for each statement which seems to be >> the only way to do this. Alternatively we could use timers, but I >> presume they just spawn threads as well. > > Timers can use one shared thread for all timers, either a generic > timer thread provided by the JVM or (IMO better in this case) one > dedicated to that timer pool. I think it'd be an ideal way to do it > personally - the JDBC driver has several issues that'd be solvable by > adding a single thread to use for various timers, etc. > > If there are concerns about the driver spawning a thread, it wouldn't > be too tricky to make timer-requiring features conditional on a > connection param, so if no connections that were going to use > timer-based features were made, no thread would be spawned. Personally > I don't think a single shared thread is worth worrying about, though. > Have you *seen* the thread lists in a modern Java app? Threads are > extremely low cost when idle, and are already heavily used throughout > Java and the JVM. Please note that you will get into problems with classloaders and different containers. E.g. running a thread from classloader will prevent this classloader to be GCd. Tomcat handles this (with a lot of warnings), but it is not recommended practice. See http://www.theserverside.com/discussions/thread.tss?thread_id=44353 or http://stackoverflow.com/questions/533783/why-spawning-threads-in-j2ee-container-is-discouraged Best regards, Vitalii Tymchyshyn
В списке pgsql-jdbc по дате отправления: