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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
