Hi, James described a corner case, but still has shown that having control over resources allocation like threads can be important. About thread management strategies, take a look at how Oracle's improve MySql 5.5 in an scalable but controllable way. * Get our "What's New in MySQL 5.5" <https://gcmprm.oracle.com/ctd/lu?RID=3-1CYOYBD&CON=&PRO=3-1CX9R0G&AID=&OID=3-1C22VFD&CID=3-1C22VEU&COID=3-1C22VFB&T=http%3a%2f%2fwww.mysql.com%2fwhy-mysql%2fwhite-papers%2fmysql-wp-whatsnew-mysql-55.php&TN=%26lt%3bfont+color%3d%22%23FF0000%22%26gt%3b%201cWhat%26amp%3b%238217%3bs+New+in+MySQL+5.5%201d%26lt%3b%2ffont%26gt%3b&RT=Clicked+On+URL> Whitepaper *
*Improved Default Thread Concurrency* -- InnoDB now defaults to allow an unlimited number of concurrently executing threads, leveraging the processing power of multi-threaded and multi-core systems. Users can override this default behavior by setting the value of innodb_thread_concurrency to the limit that best works for specific implementations. * Control of Background I/O Threads --* Users now have two new configuration parameters for all platforms, innodb_read_io_threads and innodb_write_io_threads that allow for the setting of the number of background threads used for read and write requests. This helps users tune and scale their MySQL applications on high-end, multi-core systems * Control of Master Thread I/O Rate -- *Users can now configure the overall I/O capacity and bandwidth available to InnoDB for running background tasks, via the new innodb_io_capacity in the my.cnf or my.ini files. regards, Dario El 15/12/10 16:20, Thomas Mueller escribió: > 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. -- 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.
