* Thus wrote bruce: > the method i described gives the user/app a potential way of > establsihing/maintaining/using the same connection thoughout the life of the > web app/session... > > with this approach, one could possible have the 'persistent' conection > handle to the db that i've been talking about... which would then allow for > transactional processing across multiple pages within a web app....
There are several issues that would have need to be handled to name a few: - what happens when you have 1000 visitors in an hours time span? you would need to be able to support that many connections to the database at one time. - Since http is stateless, you have no guarantee that a specific transaction will ever get committed. And possibly you're connection pool can grow to an endless number, without some sort of other layer that handles this. Unless this is a web application that is in a controlled environment, the above issues cannot be resolve very easily. Although I've probably been able to use something like this in the past, the implentation is more complicted than the benefits that are provided; and in paticular with a web application. I tend to usually change the logic so as to adhere to the limitations of a stateless environment. btw, pconnect isn't a mysql feature, it is a feature of php. Curt -- First, let me assure you that this is not one of those shady pyramid schemes you've been hearing about. No, sir. Our model is the trapezoid! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
