Партнёры:
Хостинг:
DBD::Gofer - A stateless-proxy driver for communicating with a remote DBI
use DBI;
$original_dsn = "dbi:..."; # your original DBI Data Source Name
$dbh = DBI->connect("dbi:Gofer:transport=$transport;...;dsn=$original_dsn",
$user, $passwd, \%attributes);
... use $dbh as if it was connected to $original_dsn ...
The "transport=$transport" part specifies the name of the module to use to transport the requests to the remote DBI. If $transport doesn't contain any double colons then it's prefixed with "DBD::Gofer::Transport::".
The "dsn=$original_dsn" part must be the last element of the DSN because everything after "dsn=" is assumed to be the DSN that the remote DBI should use.
The "..." represents attributes that influence the operation of the Gofer driver or transport. These are described below or in the documentation of the transport module being used.
DBD::Gofer is very similar to DBD::Proxy. The major difference is that with DBD::Gofer no state is maintained on the remote end. That means every request contains all the information needed to create the required state. (So, for example, every request includes the DSN to connect to.) Each request can be sent to any available server. The server executes the request and returns a single response that includes all the data.
This is very similar to the way http works as a stateless protocol for the web. Each request from your web browser can be handled by a different web server process.
Imagine using DBD::Gofer with an http transport. Your application calls connect(), prepare(``select * from table where foo=?''), bind_param(), and execute(). At this point DBD::Gofer builds a request containing all the information about the method calls. It then uses the httpd transport to send that request to an apache web server.
This 'dbi execute' web server executes the request (using DBI::Gofer::Execute and related modules) and builds a response that contains all the rows of data, if the statement returned any, along with all the attributes that describe the results, such as $sth->{NAME}. This response is sent back to DBD::Gofer which unpacks it and presents it to the application as if it had executed the statement itself.
Connection Pooling and Throttling
The 'dbi execute' web server leverages all the functionality of web infrastructure in terms of load balancing, high-availability, firewalls, access management, proxying, caching.
At its most basic level you get a configurable pool of persistent database connections.
Got thousands of processes all trying to connect to the database? You can use DBD::Gofer to connect them to your smaller pool of 'dbi execute' web servers instead.
Not yet implemented, but the single request-response architecture lends itself to caching.
DBD::Gofer sends as few requests as possible (dependent on the policy being used).
Thin Clients / Unsupported Platforms
You no longer need drivers for your database on every system. DBD::Gofer is pure perl.
This is because it's critical that when a request is complete the database handle is left in the same state it was when first connected.
An exception is made for attributes with names starting ""private_"": They can be set after connect() but the change is only applied locally.
An exception is made for attributes with names starting ""private_"": They can be set after prepare() but the change is only applied locally.
(In theory transactions could be supported when using a transport that maintains a connection, like "stream" does. If you're interested in this please get in touch via dbi-dev@perl.org)
Because the server-side may execute your requests via a different database connections, you can't rely on any per-connection persistent state, such as temporary tables, being available from one request to the next.
This is an easy trap to fall into. A good way to check for this is to test your code with a Gofer policy package that sets the "connect_method" policy to 'connect' to force a new connection for each request. The "pedantic" policy does this.
Some driver-private dbh attributes may not be available if the driver has not implemented the private_attribute_info() method (added in DBI 1.54).
$dbh->do($sql, { go_last_insert_id_args => [...] });
or
$sth = $dbh->prepare($sql, { go_last_insert_id_args => [...] });
The array reference should contains the args that you want passed to the last_insert_id() method.
The execute_for_fetch() method currently isn't optimised, it uses the DBI fallback behaviour of executing each tuple individually. (It could be implemented as a wrapper for execute_array() - patches welcome.)
Gofer transport modules usually come in pairs: one for the 'client' DBD::Gofer driver to use and one for the remote 'server' end. They have very similar names:
DBD::Gofer::Transport::<foo>
DBI::Gofer::Transport::<foo>
Sometimes the transports on the DBD and DBI sides may have different names. For example DBD::Gofer::Transport::http is typically used with DBI::Gofer::Transport::mod_perl (DBD::Gofer::Transport::http and DBI::Gofer::Transport::mod_perl modules are part of the GoferTransport-http distribution).
The null transport is the simplest of them all. It doesn't actually transport the request anywhere. It just serializes (freezes) the request into a string, then thaws it back into a data structure before passing it to DBI::Gofer::Execute to execute. The same freeze and thaw is applied to the results.
The null transport is the best way to test if your application will work with Gofer. Just set the DBI_AUTOPROXY environment variable to ""dbi:Gofer:transport=null;policy=pedantic"" (see ``Using DBI_AUTOPROXY'' below) and run your application, or ideally its test suite, as usual.
It doesn't take any parameters.
The pipeone transport launches a subprocess for each request. It passes in the request and reads the response.
The fact that a new subprocess is started for each request ensures that the server side is truly stateless. While this does make the transport very slow, it is useful as a way to test that your application doesn't depend on per-connection state, such as temporary tables, persisting between requests.
It's also useful both as a proof of concept and as a base class for the stream driver.
The stream driver also launches a subprocess and writes requests and reads responses, like the pipeone transport. In this case, however, the subprocess is expected to handle more that one request. (Though it will be automitically restarted if it exits.)
This is the first transport that is truly useful because it can launch the subprocess on a remote machine using "ssh". This means you can now use DBD::Gofer to easily access any databases that's accessible from any system you can login to. You also get all the benefits of ssh, including encryption and optional compression.
See ``Using DBI_AUTOPROXY'' below for an example.
See the GoferTransport-http distribution on CPAN.
I know Ask BjЬrn Hansen has implemented a transport for the "gearman" distributed job system, though it's not on CPAN at the time of writing this.
Other attributes can be specified in the DSN to configure DBD::Gofer and/or the Gofer transport module being used. The main attributes after "transport", are "url" and "policy". These are described below.
export DBI_AUTOPROXY="dbi:Gofer:transport=null"
or, for a more useful example, try:
export DBI_AUTOPROXY="dbi:Gofer:transport=stream;url=ssh:user@example.com"
The DBD::Gofer::Policy::Base class is the base class for all the policy packages and describes all the available policies.
Three policy packages are supplied with DBD::Gofer:
DBD::Gofer::Policy::pedantic is most 'transparent' but slowest because it makes more round-trips to the Gofer server.
DBD::Gofer::Policy::classic is a reasonable compromise - it's the default policy.
DBD::Gofer::Policy::rush is fastest, but may require code changes in your applications.
Generally the default "classic" policy is fine. When first testing an existing application with Gofer it is a good idea to start with the "pedantic" policy first and then switch to "classic" or a custom policy, for final testing.
This module is free software; you can redistribute it and/or modify it under the same terms as Perl itself. See perlartistic.
DBI::Gofer::Transport::Base, DBD::Gofer::Policy::Base.
Document policy mechanism
Add mechanism for transports to list config params and for Gofer to apply any that match (and warn if any left over?)
Driver-private sth attributes - set via prepare() - change DBI spec
add hooks into transport base class for checking & updating a result set cache
ie via a standard cache interface such as:
http://search.cpan.org/~robm/Cache-FastMmap/FastMmap.pm
http://search.cpan.org/~bradfitz/Cache-Memcached/lib/Cache/Memcached.pm
http://search.cpan.org/~dclinton/Cache-Cache/
http://search.cpan.org/~cleishman/Cache/
Also caching instructions could be passed through the httpd transport layer
in such a way that appropriate http cache headers are added to the results
so that web caches (squid etc) could be used to implement the caching.
(MUST require the use of GET rather than POST requests.)
Rework handling of installed_methods to not piggback on dbh_attributes?
Perhaps support transactions for transports where it's possible (ie null and stream)? Would make stream transport (ie ssh) more useful to more people.
Make sth_result_attr more like dbh_attributes (using '*' etc)
Add @val = FETCH_many(@names) to DBI in C and use in Gofer/Execute?
Implement _new_sth in C.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |