Sergi, I don't disagree with anything you said given the usual set of problems one uses something like H2 to solve. My point in response is that reserving a dedicated thread imposes a thread policy on client code may not be optimal for all problems one might use H2 to solve.
Sergi & Thomas, The system I'm working on processes documents from popular professional desktop apps. Each document is a logical database of information forming its content. This system is capable of processing thousands of these documents in a session. It is designed to break up a document into independent components and process them in parallel. This app can load down an 8 core mac pro to the limits of its memory and I/O channel. Given these documents are logically relational databases that have no dependency on one another, the most logical design choice is to assign a db per document. However, if creating a db consumes a dedicated thread, that option is off the table as there could theoretically be dozens or hundreds of documents active simultaneously depending on the particular application using the system. I don't know yet if I want to assign a db per document as I don't know the total cost of that design, but the point is that reserving a thread per db in my process would make that approach not scale well. So, quite likely, in my C++ translation, I will try to use tasks rather than dedicated threads. HOwever, I am not sure how I will approach the problem as I haven't looked at the writer subsystem carefully yet. I may not need it in the short run because in my immediate plans for the code, I don't need to write files out from memory. I just need a concurrent, in-memory, in-process store. However, I always think about the future. I imagine a task-based approach will be challenging because if a client task is doing a commit which causes a save to disk, then that task will have to block until the write task completes. Blocking in tasks should be generally avoided because a blocked thread causes the task queue manager to spawn a new thread and put a task on it to maintain the load on the system. You can eventually tie up all the threads and bring the kernel to a halt. You can get away with blocking if the the blocking is quick. Holding a lock on a mutex for a long time is bad news in a task based design. One more point....the system I am working on is designed to scale be at the heart of applications appropriate on everything from iPhones to multicore servers. I don't want to make the assumption that one more thread won't matter on a limited device like an iPhone. -James On Dec 12, 2010, at 11:43 AM, Thomas Mueller wrote: > Hi, > > For (table-level-) locking, H2 doesn't use java.util.concurrent > because this doesn't support lock upgrade. > > I guess more and more of java.util.concurrent will be used where it > makes sense, but currently there is little need for it. Areas where it > would help are (probably) seqence generation for in-memory databases. > About the background writer thread: One additional thread per database > is not that heavy, except if you have many databases open concurrently > (do you? if yes why?). Many databases use a separate process for this. > > 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. > -- 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.
