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.
