[ViewVC] Annotation of: cvs/Coro-Mysql/README

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 replaces the I/O handlers for a database connection, with
    the effect that "patched" database handles no longer block the all
    threads of a process, but only the thread that does the request.

    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, this module requires a header file that apparently isn't installed
    everywhere (violite.h), and therefore comes with it's own copy, which
    might or might not be compatible to the violite.h of your library - when
    in doubt, make sure all the libmysqlclient header files are installed
    and delete the violite.h header that comes with this module.

    On the good side, this module does a multitude of checks to ensure that
    the libray versions match on the binary level, so on incompatibilities
    you should expect an exception when trying to unblock a handle, rather
    than data corruption.

    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 to protetc
    access to a shared database handle 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.

  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).

HISTORY
    This module was initially hacked together within a few hours on a long
    flight to Malaysia, and seems to have worked ever since, with minor
    adjustments for newer libmysqlclient libraries.

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

Revision:	1.5
Committed:	Thu Oct 11 03:21:49 2012 UTC (11 years, 8 months ago) by root
Branch:	MAIN
CVS Tags:	rel-2_0, rel-1_24, rel-1_25, rel-1_26, rel-1_27, rel-1_21, rel-1_22
Changes since 1.4:	+21 -12 lines
Log Message:	1.21
#	User	Rev	Content
1	root	1.2	NAME
2			Coro::Mysql - let other threads run while doing mysql requests
3
4			SYNOPSIS
5			use Coro::Mysql;
6
7			my $DBH = Coro::Mysql::unblock DBI->connect (...);
8
9			DESCRIPTION
10			(Note that in this manual, "thread" refers to real threads as
11			implemented by the Coro module, not to the built-in windows process
12			emulation which unfortunately is also called "threads")
13
14	root	1.5	This module replaces the I/O handlers for a database connection, with
15			the effect that "patched" database handles no longer block the all
16			threads of a process, but only the thread that does the request.
17	root	1.2
18			This can be used to make parallel sql requests using Coro, or to do
19			other stuff while mysql is rumbling in the background.
20
21			CAVEAT
22	root	1.4	Note that this module must be linked against exactly the same (shared,
23			possibly not working with all OSes) libmysqlclient library as
24			DBD::mysql, otherwise it will not work.
25	root	1.2
26	root	1.5	Also, this module requires a header file that apparently isn't installed
27			everywhere (violite.h), and therefore comes with it's own copy, which
28			might or might not be compatible to the violite.h of your library - when
29			in doubt, make sure all the libmysqlclient header files are installed
30			and delete the violite.h header that comes with this module.
31
32			On the good side, this module does a multitude of checks to ensure that
33			the libray versions match on the binary level, so on incompatibilities
34			you should expect an exception when trying to unblock a handle, rather
35			than data corruption.
36
37	root	1.2	Also, while this module makes database handles non-blocking, you still
38			cannot run multiple requests in parallel on the same database handle. If
39			you want to run multiple queries in parallel, you have to create
40			multiple database connections, one for each thread that runs queries.
41	root	1.5	Not doing so can corrupt your data - use a Coro::Semaphore to protetc
42			access to a shared database handle when in doubt.
43	root	1.2
44			If you make sure that you never run two or more requests in parallel,
45	root	1.3	you can freely share the database handles between threads, of course.
46	root	1.2
47			SPEED
48			This module is implemented in XS, and as long as mysqld replies quickly
49			enough, it adds no overhead to the standard libmysql communication
50	root	1.4	routines (which are very badly written, btw.). In fact, since it has a
51			more efficient buffering and allows requests to run in parallel, it
52			often decreases the actual time to run many queries considerably.
53	root	1.2
54			For very fast queries ("select 0"), this module can add noticable
55	root	1.4	overhead (around 15%, 7% when EV can be used) as it tries to switch to
56			other coroutines when mysqld doesn't deliver the data immediately,
57			although, again, when running queries in parallel, they will usually
58			execute faster.
59	root	1.2
60	root	1.4	For most types of queries, there will be no extra latency, especially on
61	root	1.2	multicore systems where your perl process can do other things while
62			mysqld does its stuff.
63
64	root	1.3	LIMITATIONS
65			This module only supports "standard" mysql connection handles - this
66			means unix domain or TCP sockets, and excludes SSL/TLS connections,
67			named pipes (windows) and shared memory (also windows). No support for
68			these connection types is planned, either.
69
70	root	1.4	CANCELLATION
71			Cancelling a thread that is within a mysql query will likely make the
72			handle unusable. As far as Coro::Mysql is concerned, the handle can be
73			safely destroyed, but it's not clear how mysql itself will react to a
74			cancellation.
75
76	root	1.3	FUNCTIONS
77			Coro::Mysql offers a single user-accessible function:
78
79	root	1.2	$DBH = Coro::Mysql::unblock $DBH
80			This function takes a DBI database handles and "patches" it so it
81			becomes compatible to Coro threads.
82
83			After that, it returns the patched handle - you should always use
84			the newly returned database handle.
85
86	root	1.3	It is safe to call this function on any database handle (or just
87			about any value), but it will only do anything to DBD::mysql
88			handles, others are returned unchanged. That means it is harmless
89			when applied to database handles of other databases.
90
91	root	1.4	It is also safe to pass "undef", so code like this is works as
92			expected:
93
94			my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
95			or die $DBI::errstr;
96
97	root	1.3	USAGE EXAMPLE
98			This example uses PApp::SQL and Coro::on_enter to implement a function
99			"with_db", that connects to a database, uses "unblock" on the resulting
100			handle and then makes sure that $PApp::SQL::DBH is set to the
101			(per-thread) database handle when the given thread is running (it does
102			not restore any previous value of $PApp::SQL::DBH, however):
103
104			use Coro;
105			use Coro::Mysql;
106			use PApp::SQL;
107
108			sub with_db($$$&) {
109			my ($database, $user, $pass, $cb) = @_;
110
111	root	1.4	my $dbh = DBI->connect ($database, $user, $pass)->Coro::Mysql::unblock
112	root	1.3	or die $DBI::errstr;
113
114			Coro::on_enter { $PApp::SQL::DBH = $dbh };
115
116			$cb->();
117			}
118
119			This function makes it possible to easily use PApp::SQL with
120			Coro::Mysql, without worrying about database handles.
121
122			# now start 10 threads doing stuff
123			async {
124
125			with_db "DBI:mysql:test", "", "", sub {
126			sql_exec "update table set col = 5 where id = 7";
127
128			my $st = sql_exec \my ($id, $name),
129			"select id, name from table where name like ?",
130			"a%";
131
132			while ($st->fetch) {
133			...
134			}
135
136			my $id = sql_insertid sql_exec "insert into table values (1,2,3)";
137			# etc.
138			};
139
140			} for 1..10;
141
142			SEE ALSO
143			Coro, PApp::SQL (a user friendly but efficient wrapper around DBI).
144
145	root	1.5	HISTORY
146			This module was initially hacked together within a few hours on a long
147			flight to Malaysia, and seems to have worked ever since, with minor
148			adjustments for newer libmysqlclient libraries.
149
150	root	1.2	AUTHOR
151			Marc Lehmann <schmorp@schmorp.de>
152			http://home.schmorp.de/
153