Re: DB Connection parameters

Not quite sure I got the full gist of this.. A few things to note.. - remember that database connections are of type 'resource' - resources are really just integers where the number points to an array of id=>memory address - hence passing them by referece doesnt make any difference.. (as the number stays the same.. the zval only gets an extra refcount temporarily... almost all the database drivers dont actually do any connections on things like mysql_connect().. - if they are already connected.. - so the reality is that you do not really need to share a connection for all the uses of a db, however there are slight benefits in reduced overhead from a global fetch of the db object, rather than going through the overhead of working out how to connect.. below you say passing an object with a failed connect to a method may make it connect - are you sure.. a failed connection will return a pear::error.... using & only make sense if you are going to modify the PHP variables of an object.. - causing it to be copied..(in PHP4).. passing by reference for Read only (or access to resorces etc) make no difference.. - as the object is only refcounted.. It's early in the morning (with a hangover here) so excuse me if I missed the point a bit.. Regards Alan Rob Hutton wrote:

There are several packages that take DB objects like: method($dbCon); I think what this is trying to allow is reuse of a db connection. First, you are not passing a reference, but a copy of the object. This means that you are not necessarily using the same connection ID as the orignal object, so the idea of passing the object around so a connection is not created for each query may or may not be working. In fact, if no connection was made usig the original object, a new one will be made each time it is passed. This is problematic for apps that create the object in the main app and pass it through a series of methods to produce the actual output. I think the desired behavor in most situations is: method(&$dbCon); The copied object will get the same connection id if the connection on the original object has already been made. But, I'm not sure how smart the db drivers are, but having multiple object accessing the same connection may be problematic. If this is a multithreaded application, then it will definitely be problematic as you will end up with thread contention. This also holds true in an event driven model. Also, a limitation of this is that the dbCon parameter is now required. So what I would suggest would be to create a method for setting the connection to use, then make the non reference parameter optional... The last thought is that with connection pooling, then a new object does not necessarily mean a new connection. The issue is that you either need to read to the end of the result set with autofree enabled, or call free() manually to allow the connection to be used by another process... Thoughts, comments, etc. Thanks, Rob