Sounds like you may want to spend some time thinking about an overall thread-management strategy. The best policy for a tool like this is no minimize the assumptions about the environment the tool is used in and how the tool is used by client code.
I have a fair amount of experience with task-based designs. When I start thinking about the subject of H2's background threads and how to translate them into my project, I'll share whatever I come up with....if you're interested. -James On Dec 15, 2010, at 11:20 AM, Thomas Mueller wrote: > Hi, > > I guess the current behavior (one thread per database) is fine for > most use cases. For your use case, it would be better to have a > pluggable mechanism. I'm not sure how the API could look like, maybe a > database level setting to specify the writer thread factory. The > default would be to use the Database class itself as the factory. > > I plan to implement server side cursors using a separate thread, but > it's a bit tricky to get it right (my plan is to only use a separate > thread for larger result sets, which can only be detected at runtime). > In this case "separate thread" would mean a tread from some kind of > pool. Here some kind of configuration option would help. > > 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.
