Mailing List Archive

Apache::Session and Apache::DBI do not share dbi handles
I am using Apache::Session::DBI in a simple cgi script with mod_perl, and in
that same cgi I make several connections to the same database that the session
info is stored.

The several connections that I make in the cgi script using DBI->connect are
using the shared DBI handle, however Apache::Session::DBI is making a new
connection and its own 'shared' database handle

how do i know this?

i am using postgres on one machine and count the number of processes that it
starts. so lets say that running ab on the test script _without_ the sessions
it might start say 90 copies of postgres this stays relatively constant no
matter how many dbi->connects i do in the script

however if i enable Apache::Session::DBI the amount of copies of postgres
jumps to about 120 (it jumps up roughtly by the number of simulaneous
connections)

does anyone have any reason's to this behaviour? or any way to force
apache::session to use the the apache::dbi handle

--

Adam Cassar
Senior Web Developer
___________________________________________
NetRegistry http://www.netregistry.com.au
Tel: +61 2 9699 6099 | Fax: +61 2 9699 6088
PO Box 270 Broadway NSW 2007 Australia
Re: Apache::Session and Apache::DBI do not share dbi handles [ In reply to ]
Are they all using the same name and password to log into the database?
I have not looked at it in a while, but I wanted to duplicate Apache::DBI's
behavior
for a project of my own. If I remember correctly, foreach child process and
foreach name,passord pair there is one cached database handle.

cliff rayman
genwax.com

Adam Cassar wrote:

> I am using Apache::Session::DBI in a simple cgi script with mod_perl, and in
> that same cgi I make several connections to the same database that the session
> info is stored.
>
> The several connections that I make in the cgi script using DBI->connect are
> using the shared DBI handle, however Apache::Session::DBI is making a new
> connection and its own 'shared' database handle
>
> how do i know this?
>
> i am using postgres on one machine and count the number of processes that it
> starts. so lets say that running ab on the test script _without_ the sessions
> it might start say 90 copies of postgres this stays relatively constant no
> matter how many dbi->connects i do in the script
>
> however if i enable Apache::Session::DBI the amount of copies of postgres
> jumps to about 120 (it jumps up roughtly by the number of simulaneous
> connections)
>
> does anyone have any reason's to this behaviour? or any way to force
> apache::session to use the the apache::dbi handle
>
> --
>
> Adam Cassar
> Senior Web Developer
> ___________________________________________
> NetRegistry http://www.netregistry.com.au
> Tel: +61 2 9699 6099 | Fax: +61 2 9699 6088
> PO Box 270 Broadway NSW 2007 Australia
Re: Apache::Session and Apache::DBI do not share dbi handles [ In reply to ]
I got around this by hacking Apache::Session::DBIStore a wee bit to
take an already-opened database handle has a parameter to the tie
command, so it looks like (to use the example from the
Apache::Session::DBIStore docs):

tie %hash, 'Apache::Session::DBI::Sybase', $id, {
dbh => $R->db()
};

(Where a call to $R->db() returns a database handle established
elsewhere in the app)

instead of:

tie %hash, 'Apache::Session::DBI', $id, {
DataSource => 'dbi:driver:database',
UserName => 'database_user',
Password => 'K00l'
};

Since it's using an already-opened handle, you don't have to worry
about its parameters being different. You just need to make sure that
your AutoCommit and RaiseError settings are consistent with what
Apache::Session expects, or patch it further, otherwise the results
might be... inconsistent.

If you think it would be useful for you, let me know.

Thanks

Chris

* Adam Cassar (adam.cassar@netregistry.com.au) [000221 23:54]:
> I am using Apache::Session::DBI in a simple cgi script with mod_perl, and in
> that same cgi I make several connections to the same database that the session
> info is stored.
>
> The several connections that I make in the cgi script using DBI->connect are
> using the shared DBI handle, however Apache::Session::DBI is making a new
> connection and its own 'shared' database handle
>
> how do i know this?
>
> i am using postgres on one machine and count the number of processes that it
> starts. so lets say that running ab on the test script _without_ the sessions
> it might start say 90 copies of postgres this stays relatively constant no
> matter how many dbi->connects i do in the script
>
> however if i enable Apache::Session::DBI the amount of copies of postgres
> jumps to about 120 (it jumps up roughtly by the number of simulaneous
> connections)
>
> does anyone have any reason's to this behaviour? or any way to force
> apache::session to use the the apache::dbi handle
>
> --
>
> Adam Cassar
> Senior Web Developer
> ___________________________________________
> NetRegistry http://www.netregistry.com.au
> Tel: +61 2 9699 6099 | Fax: +61 2 9699 6088
> PO Box 270 Broadway NSW 2007 Australia

--
Chris Winters
Internet Developer INTES Networking
cwinters@intes.net http://www.intes.net/
Integrated hardware/software solutions to make the Internet work for you.
Re: Apache::Session and Apache::DBI do not share dbi handles [ In reply to ]
> I am using Apache::Session::DBI in a simple cgi script with mod_perl, and
in
> that same cgi I make several connections to the same database that the
session
> info is stored.
>
> The several connections that I make in the cgi script using DBI->connect
are
> using the shared DBI handle, however Apache::Session::DBI is making a new
> connection and its own 'shared' database handle

Apache::DBI uses all arguments to the connect method as the key to look up
the database handle. That means that if you have any arguments (AutoCommit,
LongReadLen, username, password, etc.) different between what you're using
in your scripts and what Apache::Session is using, it will result in
different database handles. You should look at the code in
Apache::Session::DBI, and make your connect call match it, or the other way
around.

- Perrin