Hi, Someone might think that I'm against technical progress in general and java.util.concurrent in particular, but this is not true. I'm myself heavy user of this package and really like it (even working now on my own little executors framework). But here we are talking about this package in context of existing codebase of H2. I agree that it is may be will be nice if H2 will use executors instead of threads, non- blocking IO instead of blocking and etc... But I belive for almost all of cases (may be except very specific cases) it will not make any significant difference. If you running your application with 100 threads additional few threads from H2 almost always will not be so important as you said. Do not overestimate thread cost - any modern OS on average hardware can create hundreds and even thousands of them and blocked threads usually cost only a stack in RAM which is not so huge for background threads of H2. I agree that it is still "a waste" but it is not as important as stable code base.
Also pair words about clients deciding which concurrency is better. If you are using one fixed size thread pool in your application and will push this pool to be used by all your libraries you easily can get deadlocks because all threads from the pool may try to execute task on the same pool and wait completion but there are no idle threads and they all will wait forever. So in that case you should have very clear understanding of dependencies not only between tasks in your application but also between tasks of your application and your libraries. Then you should learn internals of libraries. The simplest way to solve this without headaches is to give each library its own thread pool but this approach is not much different from having dedicated threads in libraries. The more freedom client has - the more chances that he will occasionly shoot in his leg or head and will say that libraries are bad-quality and defective.. This is not as safe as one can think. > IMHO most important aspect, is that they allow to write more safely > concurrent code out-of-the-box. I still belive for H2 now the most safe concurrent code is that already out-of-the-box exists, debugged and tested ;) But of course I agree that new code usually better to write using java.util.concurrent. regards, Sergi P.S. excuse me for too many letters.. -- 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.
