Persistent object sessions

[Ivan]

Hi,

I have a that page opens an imap connection; I need to refer to the
connection across various pages. I don't want to reopen that
connection on every page (vast waste of resources).

I have tried using sessions but they do not persist objects across
pages the php manual says that too.

I have searched all websites/forums and nobody seems to bring
up/encounter this type of problem.(refer it, if i missed)

I am used to asp where we could share a connection/object across pages
in the same website or even across websites on the same server.

I know the work around's:-
1) Reopen the connection on eve page --waste of resources
2) Save it to a database or file -- to much/complex maintenance work
for something simple.

Am I missing/not understood a feature in PHP4 or is it missing this?

Thanks
Ivan

[Phil Roberts]

With total disregard for any kind of safety measures
iv***********@f lashmail.com (Ivan) leapt forth and uttered:

I know the work around's:-
1) Reopen the connection on eve page --waste of resources
2) Save it to a database or file -- to much/complex maintenance
work for something simple.

Unfortunatly one of the major limitations of PHP is that you cannot
store resource types such as file handles or database connections.

You do have some access to persistant connections in the form of
mysql_pconnect (http://uk.php.net/mysql_pconnect), but it comes
with some disadvantages. Taken from the user notes:
Normally you do NOT want to use mysql_pconnect. This function
is designed for environments which have a high overhead to
connecting to the database. In a typical MySQL / Apache / PHP
environment, Apache will create many child processes which lie
in idle waiting for a web request to be assigned to them. Each
of these child processes will open and hold its own MySQL
connection. So if you have a MySQL server which has a limit of
50 connections, but Apache keeps more than 50 child processes
running, each of these child processes can hold a connection to
your MySQL server, even while they are idle (idle httpd child
processes don't lend their MySQL connection to other httpd
children, they hold their own). So even if you only have a few
pages which actually connect to MySQL on a busy site, you can
run out of connections, with all of them not actually being
used.

--
Phil Roberts | Dork Pretending To Be Hard | http://www.flatnet.net/

[Ivan]

Phil Roberts <ph*****@HOLYfl atnetSHIT.net> wrote in message news:<Xn******* *************** ***@216.196.97. 132>...

With total disregard for any kind of safety measures
iv***********@f lashmail.com (Ivan) leapt forth and uttered:

I know the work around's:-
1) Reopen the connection on eve page --waste of resources
2) Save it to a database or file -- to much/complex maintenance
work for something simple.

-- One has to do the "not-so obvious" when the "obvious is not-so"
Unfortunatly one of the major limitations of PHP is that you cannot
store resource types such as file handles or database connections.
Thanks, hope we see this feature in later versions

You do have some access to persistant connections in the form of
mysql_pconnect (http://uk.php.net/mysql_pconnect), but it comes
with some disadvantages. Taken from the user notes:

Normally you do NOT want to use mysql_pconnect. This function
is designed for environments which have a high overhead to
connecting to the database. In a typical MySQL / Apache / PHP
environment, Apache will create many child processes which lie
in idle waiting for a web request to be assigned to them. Each
of these child processes will open and hold its own MySQL
connection. So if you have a MySQL server which has a limit of
50 connections, but Apache keeps more than 50 child processes
running, each of these child processes can hold a connection to
your MySQL server, even while they are idle (idle httpd child
processes don't lend their MySQL connection to other httpd
children, they hold their own). So even if you only have a few
pages which actually connect to MySQL on a busy site, you can
run out of connections, with all of them not actually being
used.