/ 
Coro-Mysql-1.1
River stage zero No dependents
/ Coro::Mysql

NAME

Coro::Mysql - let other threads run while doing mysql requests

SYNOPSIS

use Coro::Mysql;

my $DBH = Coro::Mysql::unblock DBI->connect (...);

DESCRIPTION

(Note that in this manual, "thread" refers to real threads as implemented by the Coro module, not to the built-in windows process emulation which unfortunately is also called "threads")

This module "patches" DBD::mysql database handles so that they do not block the whole process, but only the thread that they are used in.

This can be used to make parallel sql requests using Coro, or to do other stuff while mysql is rumbling in the background.

CAVEAT

Note that this module must be linked against exactly the same (shared, possibly not working with all OSes) libmysqlclient library as DBD::mysql, otherwise it will not work.

Also, while this module makes database handles non-blocking, you still cannot run multiple requests in parallel on the same database handle. If you want to run multiple queries in parallel, you have to create multiple database connections, one for each thread that runs queries. Not doing so can corrupt your data - use a Coro::Semaphore when in doubt.

If you make sure that you never run two or more requests in parallel, you can freely share the database handles between threads, of course.

Also, this module uses a number of "unclean" techniques (patching an internal libmysql structure for one thing) and was initially hacked within a few hours on a long flight to Malaysia.

It does, however, check whether it indeed got the structure layout correct, so you should expect perl exceptions or early crashes as opposed to data corruption when something goes wrong during patching.

SPEED

This module is implemented in XS, and as long as mysqld replies quickly enough, it adds no overhead to the standard libmysql communication routines (which are very badly written, btw.). In fact, since it has a more efficient buffering and allows requests to run in parallel, it often decreases the actual time to run many queries considerably.

For very fast queries ("select 0"), this module can add noticable overhead (around 15%, 7% when EV can be used) as it tries to switch to other coroutines when mysqld doesn't deliver the data immediately, although, again, when running queries in parallel, they will usually execute faster.

For most types of queries, there will be no extra latency, especially on multicore systems where your perl process can do other things while mysqld does its stuff.

LIMITATIONS

This module only supports "standard" mysql connection handles - this means unix domain or TCP sockets, and excludes SSL/TLS connections, named pipes (windows) and shared memory (also windows). No support for these connection types is planned, either.

CANCELLATION

Cancelling a thread that is within a mysql query will likely make the handle unusable. As far as Coro::Mysql is concerned, the handle can be safely destroyed, but it's not clear how mysql itself will react to a cancellation.

FUNCTIONS

Coro::Mysql offers a single user-accessible function:

$DBH = Coro::Mysql::unblock $DBH

This function takes a DBI database handles and "patches" it so it becomes compatible to Coro threads.

After that, it returns the patched handle - you should always use the newly returned database handle.

It is safe to call this function on any database handle (or just about any value), but it will only do anything to DBD::mysql handles, others are returned unchanged. That means it is harmless when applied to database handles of other databases.

It is also safe to pass undef, so code like this is works as expected:

my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
   or die $DBI::errstr;

USAGE EXAMPLE

This example uses PApp::SQL and Coro::on_enter to implement a function with_db, that connects to a database, uses unblock on the resulting handle and then makes sure that $PApp::SQL::DBH is set to the (per-thread) database handle when the given thread is running (it does not restore any previous value of $PApp::SQL::DBH, however):

use Coro;
use Coro::Mysql;
use PApp::SQL;

sub with_db($$$&) {
   my ($database, $user, $pass, $cb) = @_;

   my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
      or die $DBI::errstr;

   Coro::on_enter { $PApp::SQL::DBH = $dbh };

   $cb->();
}

This function makes it possible to easily use PApp::SQL with Coro::Mysql, without worrying about database handles.

# now start 10 threads doing stuff
async {

   with_db "DBI:mysql:test", "", "", sub {
      sql_exec "update table set col = 5 where id = 7";

      my $st = sql_exec \my ($id, $name),
                        "select id, name from table where name like ?",
                        "a%";

      while ($st->fetch) {
         ...
      }

      my $id = sql_insertid sql_exec "insert into table values (1,2,3)";
      # etc.
   };

} for 1..10;

SEE ALSO

Coro, PApp::SQL (a user friendly but efficient wrapper around DBI).

AUTHOR

Marc Lehmann <schmorp@schmorp.de>
http://home.schmorp.de/