On 5/7/07, Jonathan Vanasco <[EMAIL PROTECTED]> wrote:
I thought the same as you , until that lighttpd posting ( March 2006 ). But according to Jan , who was at MySQL at the time , MySQL only had a synchronous API. An async was on a todo list, but selects were blocking on the whole server.
There are two different concepts here. The first is how the RDBMS handles locking. This is pretty simple. MyISAM tables use shared read locks and exclusive write locks. InnoDB tables use an MVCC approach like Postgres and Oracle. Readers do not block readers with either one. Then there's the network transport layer. Lighttpd uses the same approach as memcached or POE, i.e. a single process that multiplexes between active connections using some kind of polling. This is usually called asynchronous or non-blocking I/O. There are no databases I'm aware of that provide an asynchronous network library. They all assume you will send a query and then wait for the response, blocking within that thread/process until the response comes back. A system like mod_perl which dedicates a process or thread to each request has no problem with this, since one waiting thread doesn't block any others. It's a disaster for Lighttpd because any blocking I/O means the entire server has to sit and wait. (Note that this is only for database calls made from directly within the server. Most Lighttpd users write their applications in separate processes like FastCGI that have the same multi-process model mod_perl does.) This is why there are a bunch of plugins for POE to let you do DBI queries. They do things like fork before sending the query, since if they did it from within POE it would make the whole thing sit and wait for the results. This is also why I'm always skeptical when people come along saying they are going to switch to a non-blocking process model and beat the pants off apache. Using that model complicates everything, and makes the majority of network libraries useless unless you do tricks like forking before you use them. If you're interested in using non-blocking I/O from perl, Stas Bekman wrote an article about it here: http://www.onlamp.com/pub/a/onlamp/2006/10/12/asynchronous_events.html - Perrin
