In the case where you run as a standalone server, you're right. In the case where you are running as an in process db and h2 is competing for threads with the rest of the app, you aren't so right. Threads are a finite resource. It is very easy to create enough threads to bring the entire os to a crawl. Having a thread hanging around dedicated to a specific, intermittent task is a waste. This design could be a problem in a high performance app or a highly concurrent app. Also, if you are designing a big app utilizing many 3rd party libraries, and they are each reserving dedicated threads, this could cause problems for you. Its best if libraries don't impose thread management policy on clients, but let the clients decide on the policy. These new concurrency APIs make that sort of design practical.
I'm not seeking to convince you to make this change. I'm just explaining why you might want to consider it some day since the subject was brought up. -James On Dec 11, 2010, at 12:40 AM, Sergi Vladykin wrote: > Hi, > > There are only few such background threads so you will not gain > anything measurable by replacing them with pool. > > And yes, java.util.concurrent was not used for compatibility with java > 1.4. > > regards, > Sergi > > -- > 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. > -- 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.
