Hello, > > > 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.
in my case its 2 per database and that means that ~2/3 of the threads of the application are H2 Lock/Log threads. The application uses so many small databases because it creates one per customer (data needs to be separated) and having them embedded allows for easy/automatic creation of new ones. Once a database grows to big/ demanding it will be moved to a DB-server to also improve cache- efficiency but so far all DBs are well within limits. I will investigate the use of FS locking for my application, that would kill 1 thread per DB. The application can check that no DB is opened twice but sometimes we need to do maintenance with external tools (eg. H2 console) and therefor the DB needs to be protected when in use by the application. I agree that thread-pools are not the ideal solution here so when I have a look at the code my aim will be to get rid of the log-thread. If there was a possibility to do threadless logging I could get rid of all the H2 threads. regards Wolfgang -- 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.
