The latest versions of Java support 10s of thousands of threads. When they are idle the OS swaps out the memory pages and there is very little overhead.
http://vanillajava.blogspot.com/2011/07/java-what-is-limit-to-number-of-threads.html http://stackoverflow.com/questions/2117072/java-thread-creation-overhead On Sat, Feb 18, 2012 at 16:54, Christoph Läubrich <lae...@googlemail.com> wrote: > A CachedThreadpool won't change anything here, it is only usefull if you > have many short living threads because it reduces the overhead assosiated > with allocating a thread. > The Thread count is manly bound by the threads stack size and the OS and not > by the JVM itself. If the thread is really inactive (aka blocked on a wait > or something) it won't harm the VM much. In cases of low (system) memory it > is also likely that the parts which are inactive are swapped out. > > >> What specific problems are you worried about? > Every feature is a potential place for bugs. > > >> This is useful for large computer farms > Exspecially in this case you won't have all threads running on the same > CPU/Host.. > > Am 18.02.2012 15:34, schrieb cowwoc: > > Thomas, > > My understanding is that idle threads (even if they are one per > database) will eat up valuable memory. The last time I checked Java would > only allow you to launch a few thousand threads (2000 or so). By introducing > a thread pool you're allowing the user to run more databases but have the > same number of databases active. For example, run 1 million instances but > only 2000 are active at any given time. This is useful for large computer > farms (think cloud computing) where you have literally millions of instances > running, but only a few active at a time. > > I think we can have the best of both worlds by allowing users to specify > a non-blocking Thread Pool such as Executors.newCachedThreadPool(). What > specific problems are you worried about? > > Gili > > On 18/02/2012 2:26 AM, Thomas Mueller wrote: > > Hi, > > Opening many databases concurrently is problematic anyway: > > - out-of-memory problems when using the default cache settings > - bad or cache hit rate / very bad cache efficiency > - "too many open files" problem > > I would consider using a small number of concurrently open databases > (for example 100). I don't see it as a priority currently to support > tens of thousands of concurrently open databases. > > IMHO permanently reducing the number of idle threads can always be > beneficial > > H2 doesn't use that many threads - just one per database usually. I > think using a thread pool would cause more problems that it would > solve, so I'm against going in this direction. But if you want to > implement it and want to provide it for others to use, please go > ahead. > > Regards, > Thomas > > > > -- > You received this message because you are subscribed to the Google Groups > "H2 Database" group. > To post to this group, send email to h2-database@googlegroups.com. > To unsubscribe from this group, send email to > h2-database+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/h2-database?hl=en. -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-database@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
