Re: Bug #850 Updated: pconnects fail if database has released session

From: Date: Thu, 22 Oct 1998 11:12:03 +0000
Subject: Re: Bug #850 Updated: pconnects fail if database has released session
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-1958@lists.php.net to get a copy of this message
Bug Database wrote: > ID: 850 > Updated by: kara > Reported By: peter.lerner@bayreuth.baynet.de > Status: Assigned > Bug Type: Adabas-D related > Assigned To: kara > Comments: > Does this happen with a remote database connection or a local connection? > I have found that for connections to a local Adabas database, the connection is > implicitly reopened. I didn't try this for a remote connection. this happens with a remote connection, webserver / database on different computers. i have not the deeper knowledge into adabas to see why local connections should have other timeouts ... perhaps they are handled completly different. btw ... what are "local" connections? i access adabas via php3's odbc-commands, with an odbc datasource. isn't it that all connections are implicit network (=remote) connections and REMOTE SQL must be started for adabas to function properly? [jakob] servernode=styx.courant.de serverdb=JAKOB > A first workaround could be to set the connection timeout in Adabas to a higher > value. in the long run this would eat up too much "persistent" sessions. imagine someone running a ten user license ... btw ... i work with php3 as an apache module. how many persistent connections/sessions are established with the database? does the configuration of apache's spareservers influence the number of connections/sessions ? e.g. ###### httpd.conf ######## ... MinSpareServers 5 MaxSpareServers 10 StartServers 5 ... ########################## these are the different kinds of timeouts you can configure in the database kernel ... -------------------------- snip --------------------------- SESSION TIMEOUT (default 900 secs) This parameter defines the maximum time of inactivity allowed for all database sessions. The specification is made in seconds. If no SQL statement is issued within the specified time, the database session concerned is implicitly terminated with ROLLBACK WORK RELEASE. LOCK TIMEOUT (default 360 secs) This parameter defines the maximum time of inactivity allowed for all database sessions holding locks. The specification is made in seconds. If no SQL statement is issued within the specified time and if there are other users waiting for the lock to be released, the transaction concerned is implicitly rolled back with ROLLBACK WORK. REQUEST TIMEOUT (default 180 secs) This parameter restricts the waiting time for a lock release for all database sessions. The specification is made in seconds. If a lock request cannot be satisfied within the time thus defined, a message is returned to the waiting database session. -------------------------- snip --------------------------- > Full Bug description available at: > http://ca.php.net/bugs.php3?id=850 mfg peter lerner -- /earth is 98% full ... please delete anyone you can. -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net

« previous php.dev (#1958) next »