| Name : perl-Apache-DBI
| |
| Version : 1.12
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : 1.67
| Date : 2024-08-05 17:47:43
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Apache-DBI-1.12-1.67.src.rpm
|
| Size : 0.13 MB
| |
| Packager : (none)
| |
| Summary : Initiate a persistent database connection
|
Description :
This module initiates a persistent database connection.
The database access uses Perl\'s DBI. For supported DBI drivers see:
http://dbi.perl.org/
When loading the DBI module (do not confuse this with the Apache::DBI
module) it checks if the environment variable \'MOD_PERL\' has been set and
if the module Apache::DBI has been loaded. In this case every connect
request will be forwarded to the Apache::DBI module. This checks if a
database handle from a previous connect request is already stored and if
this handle is still valid using the ping method. If these two conditions
are fulfilled it just returns the database handle. The parameters defining
the connection have to be exactly the same, including the connect
attributes! If there is no appropriate database handle or if the ping
method fails, a new connection is established and the handle is stored for
later re-use. There is no need to remove the disconnect statements from
your code. They won\'t do anything because the Apache::DBI module overloads
the disconnect method.
The Apache::DBI module still has a limitation: it keeps database
connections persistent on a per process basis. The problem is, if a user
accesses a database several times, the http requests will be handled very
likely by different processes. Every process needs to do its own connect.
It would be nice if all servers could share the database handles, but
currently this is not possible because of the distinct memory-space of each
process. Also it is not possible to create a database handle upon startup
of the httpd and then inherit this handle to every subsequent server. This
will cause clashes when the handle is used by two processes at the same
time. Apache::DBI has built-in protection against this. It will not make a
connection persistent if it sees that it is being opened during the server
startup. This allows you to safely open a connection for grabbing data
needed at startup and disconnect it normally before the end of startup.
With this limitation in mind, there are scenarios, where the usage of
Apache::DBI is depreciated. Think about a heavy loaded Web-site where every
user connects to the database with a unique userid. Every server would
create many database handles each of which spawning a new backend process.
In a short time this would kill the web server.
Another problem are timeouts: some databases disconnect the client after a
certain period of inactivity. The module tries to validate the database
handle using the \'ping()\' method of the DBI-module. This method returns
true by default. Most DBI drivers have a working \'ping()\' method, but if
the driver you\'re using doesn\'t have one and the database handle is no
longer valid, you will get an error when accessing the database. As a
work-around you can try to add your own \'ping()\' method using any database
command which is cheap and safe, or you can deactivate the usage of the
ping method (see CONFIGURATION below).
Here is a generalized ping method, which can be added to the driver module:
package DBD::xxx::db; # ====== DATABASE ======
use strict;
sub ping {
my ($dbh) = AATT_;
my $ret = 0;
eval {
local $SIG{__DIE__} = sub { return (0); };
local $SIG{__WARN__} = sub { return (0); };
$ret = $dbh->do(\'select 1\');
};
return ($AATT) ? 0 : $ret;
}
Transactions: a standard DBI script will automatically perform a rollback
whenever the script exits. In the case of persistent database connections,
the database handle will not be destroyed and hence no automatic rollback
will occur. At a first glance it even seems possible to handle a
transaction over multiple requests. But this should be avoided, because
different requests are handled by different processes and a process does
not know the state of a specific transaction which has been started by
another process. In general, it is good practice to perform an explicit
commit or rollback at the end of every request. In order to avoid
inconsistencies in the database in case AutoCommit is off and the script
finishes without an explicit rollback, the Apache::DBI module uses a
PerlCleanupHandler to issue a rollback at the end of every request. Note,
that this CleanupHandler will only be used, if the initial data_source sets
AutoCommit = 0 or AutoCommit is turned off, after the connect has been done
(ie begin_work). However, because a connection may have set other
parameters, the handle is reset to its initial connection state before it
is returned for a second time.
This module plugs in a menu item for Apache::Status or Apache2::Status. The
menu lists the current database connections. It should be considered
incomplete because of the limitations explained above. It shows the current
database connections for one specific process, the one which happens to
serve the current request. Other processes might have other database
connections. The Apache::Status/Apache2::Status module has to be loaded
before the Apache::DBI module !
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-A/openSUSE_Tumbleweed/noarch |
