Menu
▾
▴
apc-aa-coders
|
From: Mitra <mi...@ea...> - 2003-02-16 21:32:01
|
One change of note is to add functions getDB and freeDB so that there is no longer the risk of one operation mucking up an in-process DB action. Basically instead of trying to decide whether to use globals $db $db2 or $db3 instead just go $db = getDB() $db->normal db ops freeDB($db) The system keeps an array of unused $db's so that we still get the advantages of keeping connections open. I have NOT incorporated this into the existing code, - since to do so would inevitably involve making one or more mistakes that broke something!, but I will do whenever I'm working on something. - Mitra -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Jakub A. <jak...@se...> - 2003-02-17 19:56:58
|
Mitra, the PHPlib approach of having the DB connection and recordset in one class is a bit strange. The result is, we should create a new recordset DB_AA for each SELECT query. The current approach of using one recordset everywhere is perhaps caused by the name DB_AA which looks like database and usually only one database is used. It is surely wrong. I am not sure, but my idea was that the persistent connections are kept by PHP and not by individual scripts and thus creating a new DB_AA would waste no time as it uses always only finds a persisten connection? It this is the case, getDB and freeDB are not needed because they only duplicate this behavior. One more remark: Your approach seems to me a bit uncovenient. The problem is you must call freeDB() every time you exit any function. Surely somebody will forget to do so at least in some places where he or she uses "return". In C++ such things are solved by constructors and destructors, but PHP has no destructors. On the other hand this will perhaps do no much damage as the not-freed DBs will be closed as the script finishes. Jakub > -----Original Message----- > From: apc...@li... > [mailto:apc...@li...] On Behalf Of Mitra > Sent: Sunday, February 16, 2003 10:56 AM > To: apc...@so... > Subject: [Apc-aa-coders] getDB and freeDB > > > One change of note is to add functions getDB and freeDB so that there > is no longer the risk of one operation mucking up an in-process DB > action. > > Basically instead of trying to decide whether to use globals $db $db2 > or $db3 instead just go > > > $db = getDB() > $db->normal db ops > freeDB($db) > > The system keeps an array of unused $db's so that we still get the > advantages of keeping connections open. > > I have NOT incorporated this into the existing code, - since to do so > would inevitably involve making one or more mistakes that broke > something!, but I will do whenever I'm working on something. > > - Mitra > > -- > Mitra Technology Consulting - www.mitra.biz - > mi...@mi... 02-6684-8096 or 0414-648-0722 > > Life is a Mystery to be Lived, not a Problem to be Solved > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Apc-aa-coders mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > |
|
From: Mitra <mi...@ea...> - 2003-02-17 22:08:49
|
You could be correct, I'm not sure if PHP caches connections. What I KNOW to be bad is using $db, $db2, and $db3 because if in the middle of using $db to fetch records, then you use a function call (for example to turn and id into a name) and this uses the same $db then you break things. Its a recipe for bugs. So I see two solutiosn 1: $db = new DB_AA() ; use the $db ; or 2: $db = getDB; use the $db ; freeDB($db) Actually, I can't see how #1 (or the current way of doing things) can reuse database connections, because how does PHP know when you've finished with the SELECT? yes - there could be a problem with "return" without freeing the db, but I'd rather have an occasional inefficiency, than a big problem with possible bugs. I'm not making any mass changes, just changing the code as I work on it, so I think it will be easy to do it carefully. - Mitra At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: >Mitra, > >the PHPlib approach of having the DB connection and recordset in one >class is a bit strange. The result is, we should create a new recordset >DB_AA for each SELECT query. The current approach of using one recordset >everywhere is perhaps caused by the name DB_AA which looks like database >and usually only one database is used. It is surely wrong. > >I am not sure, but my idea was that the persistent connections are kept >by PHP and not by individual scripts and thus creating a new DB_AA would >waste no time as it uses always only finds a persisten connection? It >this is the case, getDB and freeDB are not needed because they only >duplicate this behavior. > >One more remark: Your approach seems to me a bit uncovenient. The >problem is you must call freeDB() every time you exit any function. >Surely somebody will forget to do so at least in some places where he or >she uses "return". In C++ such things are solved by constructors and >destructors, but PHP has no destructors. On the other hand this will >perhaps do no much damage as the not-freed DBs will be closed as the >script finishes. > >Jakub > >> -----Original Message----- >> From: apc...@li... >> [mailto:apc...@li...] On Behalf Of Mitra >> Sent: Sunday, February 16, 2003 10:56 AM >> To: apc...@so... >> Subject: [Apc-aa-coders] getDB and freeDB >> >> >> One change of note is to add functions getDB and freeDB so that there >> is no longer the risk of one operation mucking up an in-process DB >> action. >> >> Basically instead of trying to decide whether to use globals $db $db2 >> or $db3 instead just go >> >> >> $db = getDB() >> $db->normal db ops >> freeDB($db) >> >> The system keeps an array of unused $db's so that we still get the >> advantages of keeping connections open. >> >> I have NOT incorporated this into the existing code, - since to do so >> would inevitably involve making one or more mistakes that broke >> something!, but I will do whenever I'm working on something. >> >> - Mitra >> >> -- >> Mitra Technology Consulting - www.mitra.biz - >> mi...@mi... 02-6684-8096 or 0414-648-0722 >> >> Life is a Mystery to be Lived, not a Problem to be Solved >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Apc-aa-coders mailing list >> Apc...@li... > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Mitra <mi...@ea...> - 2003-02-25 04:58:24
|
Jakub, Honza Are we happy with the way I'm suggesting to do this ? - Mitra At 9:03 AM +1100 18/2/03, Mitra wrote: >You could be correct, I'm not sure if PHP caches connections. > >What I KNOW to be bad is using $db, $db2, and $db3 because if in the >middle of using $db to fetch records, then you use a function call >(for example to turn and id into a name) and this uses the same $db >then you break things. Its a recipe for bugs. > >So I see two solutiosn > >1: $db = new DB_AA() ; use the $db ; >or >2: $db = getDB; use the $db ; freeDB($db) > >Actually, I can't see how #1 (or the current way of doing things) >can reuse database connections, because how does PHP know when >you've finished with the SELECT? > >yes - there could be a problem with "return" without freeing the db, >but I'd rather have an occasional inefficiency, than a big problem >with possible bugs. I'm not making any mass changes, just changing >the code as I work on it, so I think it will be easy to do it >carefully. > >- Mitra > > >At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: >>Mitra, >> >>the PHPlib approach of having the DB connection and recordset in one >>class is a bit strange. The result is, we should create a new recordset >>DB_AA for each SELECT query. The current approach of using one recordset >>everywhere is perhaps caused by the name DB_AA which looks like database >>and usually only one database is used. It is surely wrong. >> >>I am not sure, but my idea was that the persistent connections are kept >>by PHP and not by individual scripts and thus creating a new DB_AA would >>waste no time as it uses always only finds a persisten connection? It >>this is the case, getDB and freeDB are not needed because they only >>duplicate this behavior. >> >>One more remark: Your approach seems to me a bit uncovenient. The >>problem is you must call freeDB() every time you exit any function. >>Surely somebody will forget to do so at least in some places where he or >>she uses "return". In C++ such things are solved by constructors and >>destructors, but PHP has no destructors. On the other hand this will >>perhaps do no much damage as the not-freed DBs will be closed as the >>script finishes. >> >>Jakub >> >>> -----Original Message----- >>> From: apc...@li... >>> [mailto:apc...@li...] On Behalf Of Mitra >>> Sent: Sunday, February 16, 2003 10:56 AM >>> To: apc...@so... >>> Subject: [Apc-aa-coders] getDB and freeDB >>> >>> >>> One change of note is to add functions getDB and freeDB so that there >>> is no longer the risk of one operation mucking up an in-process DB >>> action. >>> >>> Basically instead of trying to decide whether to use globals $db $db2 >>> or $db3 instead just go >>> >>> >>> $db = getDB() >>> $db->normal db ops >>> freeDB($db) >>> >>> The system keeps an array of unused $db's so that we still get the >>> advantages of keeping connections open. >>> >>> I have NOT incorporated this into the existing code, - since to do so >> > would inevitably involve making one or more mistakes that broke >> > something!, but I will do whenever I'm working on something. >> > >> > - Mitra >> > >> > -- >> > Mitra Technology Consulting - www.mitra.biz - >>> mi...@mi... 02-6684-8096 or 0414-648-0722 >>> >>> Life is a Mystery to be Lived, not a Problem to be Solved >>> >>> >>> >>> ------------------------------------------------------- >>> This sf.net email is sponsored by:ThinkGeek >>> Welcome to geek heaven. >>> http://thinkgeek.com/sf >>> _______________________________________________ >>> Apc-aa-coders mailing list >>> Apc...@li... >> > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders >> > > > >-- >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Mitra <mi...@ea...> - 2003-03-03 03:15:28
|
Repeat ... Honza, I'd like to know what you think of this, before I make changes to code as I work on it. - Mitra At 2:56 PM +1100 25/2/03, Mitra wrote: >Jakub, Honza > >Are we happy with the way I'm suggesting to do this ? > >- Mitra > > >At 9:03 AM +1100 18/2/03, Mitra wrote: >>You could be correct, I'm not sure if PHP caches connections. >> >>What I KNOW to be bad is using $db, $db2, and $db3 because if in >>the middle of using $db to fetch records, then you use a function >>call (for example to turn and id into a name) and this uses the >>same $db then you break things. Its a recipe for bugs. >> >>So I see two solutiosn >> >>1: $db = new DB_AA() ; use the $db ; >>or >>2: $db = getDB; use the $db ; freeDB($db) >> >>Actually, I can't see how #1 (or the current way of doing things) >>can reuse database connections, because how does PHP know when >>you've finished with the SELECT? >> >>yes - there could be a problem with "return" without freeing the >>db, but I'd rather have an occasional inefficiency, than a big >>problem with possible bugs. I'm not making any mass changes, just >>changing the code as I work on it, so I think it will be easy to do >>it carefully. >> >>- Mitra >> >> >>At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: >>>Mitra, >>> >>>the PHPlib approach of having the DB connection and recordset in one >>>class is a bit strange. The result is, we should create a new recordset >>>DB_AA for each SELECT query. The current approach of using one recordset >>>everywhere is perhaps caused by the name DB_AA which looks like database >>>and usually only one database is used. It is surely wrong. >>> >>>I am not sure, but my idea was that the persistent connections are kept >>>by PHP and not by individual scripts and thus creating a new DB_AA would >>>waste no time as it uses always only finds a persisten connection? It >>>this is the case, getDB and freeDB are not needed because they only >>>duplicate this behavior. >>> >>>One more remark: Your approach seems to me a bit uncovenient. The >>>problem is you must call freeDB() every time you exit any function. >>>Surely somebody will forget to do so at least in some places where he or >>>she uses "return". In C++ such things are solved by constructors and >>>destructors, but PHP has no destructors. On the other hand this will >>>perhaps do no much damage as the not-freed DBs will be closed as the >>>script finishes. >>> >>>Jakub >>> >>>> -----Original Message----- >>>> From: apc...@li... >>>> [mailto:apc...@li...] On Behalf Of Mitra >>>> Sent: Sunday, February 16, 2003 10:56 AM >>>> To: apc...@so... >>>> Subject: [Apc-aa-coders] getDB and freeDB >>>> >>>> >>>> One change of note is to add functions getDB and freeDB so that there >>>> is no longer the risk of one operation mucking up an in-process DB >>>> action. >>>> >>>> Basically instead of trying to decide whether to use globals $db $db2 >>>> or $db3 instead just go >>>> >>>> >>>> $db = getDB() >>>> $db->normal db ops >>>> freeDB($db) >>>> >>>> The system keeps an array of unused $db's so that we still get the >>> > advantages of keeping connections open. >>> > >>> > I have NOT incorporated this into the existing code, - since to do so >>> > would inevitably involve making one or more mistakes that broke >>> > something!, but I will do whenever I'm working on something. >>> > >>> > - Mitra >>> > >>> > -- >>> > Mitra Technology Consulting - www.mitra.biz - >>>> mi...@mi... 02-6684-8096 or 0414-648-0722 >>>> >>>> Life is a Mystery to be Lived, not a Problem to be Solved >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This sf.net email is sponsored by:ThinkGeek >>>> Welcome to geek heaven. >>>> http://thinkgeek.com/sf >>>> _______________________________________________ >>>> Apc-aa-coders mailing list >>>> Apc...@li... >>> > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders >>> > >> >> >>-- >>Mitra Technology Consulting - www.mitra.biz - mi...@mi... >>02-6684-8096 or 0414-648-0722 >> >>Life is a Mystery to be Lived, not a Problem to be Solved > > >-- >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Jakub A. <jak...@se...> - 2003-03-03 10:35:58
|
I am not sure when PHP frees variables, perhaps on leaving a function, surely not later than on finishing the script. This way it knows you finished your SELECT. My suggestion is not to use "global $db" but "$db = new DB_AA" which should be sufficient. Perhaps you could measure how much time (if any) it takes to create a new DB_AA. Jakub -----Original Message----- From: apc...@li... [mailto:apc...@li...] On Behalf Of Mitra Sent: Tuesday, February 25, 2003 4:56 AM To: Jakub Adamek; apc...@so... Subject: RE: [Apc-aa-coders] getDB and freeDB Jakub, Honza Are we happy with the way I'm suggesting to do this ? - Mitra At 9:03 AM +1100 18/2/03, Mitra wrote: You could be correct, I'm not sure if PHP caches connections. What I KNOW to be bad is using $db, $db2, and $db3 because if in the middle of using $db to fetch records, then you use a function call (for example to turn and id into a name) and this uses the same $db then you break things. Its a recipe for bugs. So I see two solutiosn 1: $db = new DB_AA() ; use the $db ; or 2: $db = getDB; use the $db ; freeDB($db) Actually, I can't see how #1 (or the current way of doing things) can reuse database connections, because how does PHP know when you've finished with the SELECT? yes - there could be a problem with "return" without freeing the db, but I'd rather have an occasional inefficiency, than a big problem with possible bugs. I'm not making any mass changes, just changing the code as I work on it, so I think it will be easy to do it carefully. - Mitra At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: Mitra, the PHPlib approach of having the DB connection and recordset in one class is a bit strange. The result is, we should create a new recordset DB_AA for each SELECT query. The current approach of using one recordset everywhere is perhaps caused by the name DB_AA which looks like database and usually only one database is used. It is surely wrong. I am not sure, but my idea was that the persistent connections are kept by PHP and not by individual scripts and thus creating a new DB_AA would waste no time as it uses always only finds a persisten connection? It this is the case, getDB and freeDB are not needed because they only duplicate this behavior. One more remark: Your approach seems to me a bit uncovenient. The problem is you must call freeDB() every time you exit any function. Surely somebody will forget to do so at least in some places where he or she uses "return". In C++ such things are solved by constructors and destructors, but PHP has no destructors. On the other hand this will perhaps do no much damage as the not-freed DBs will be closed as the script finishes. Jakub > -----Original Message----- > From: apc...@li... > [mailto:apc...@li...] On Behalf Of Mitra > Sent: Sunday, February 16, 2003 10:56 AM > To: apc...@so... > Subject: [Apc-aa-coders] getDB and freeDB > > > One change of note is to add functions getDB and freeDB so that there > is no longer the risk of one operation mucking up an in-process DB > action. > > Basically instead of trying to decide whether to use globals $db $db2 > or $db3 instead just go > > > $db = getDB() > $db->normal db ops > freeDB($db) > > The system keeps an array of unused $db's so that we still get the > advantages of keeping connections open. > > I have NOT incorporated this into the existing code, - since to do so > would inevitably involve making one or more mistakes that broke > something!, but I will do whenever I'm working on something. > > - Mitra > > -- > Mitra Technology Consulting - www.mitra.biz - > mi...@mi... 02-6684-8096 or 0414-648-0722 > > Life is a Mystery to be Lived, not a Problem to be Solved > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Apc-aa-coders mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Mitra <mi...@ea...> - 2003-03-03 22:18:22
|
Jakub The issue is NOT about creating and destroying variables. What we are trying to achieve is to make sure database connections are cached. if you use local variables - e.g. $db = new DB_AA - then I believe the variable will be destroyed and the database connection dropped at the end of the function. If you use global variables - i.e. global $db - then you share the database connection, but there is a significant risk that an inner function will try and use a database connection still being used at the outer level. getDB and freeDB use a database pool, look at the definitions in util.php3 to see how, a function grabs a free DB_AA and then releases it when finished. That way only the minimum needed number of DB_AA (and Database connections) get created. I'm making assumptions about how PHP manages its database connections, which is why I'm asking this question, in case either of you have more information. - Mitra At 11:35 AM +0100 3/3/03, Jakub Adamek wrote: >I am not sure when PHP frees variables, perhaps on leaving a >function, surely not later than on finishing the script. This way it >knows you finished your SELECT. My suggestion is not to use "global >$db" but "$db = new DB_AA" which should be sufficient. Perhaps you >could measure how much time (if any) it takes to create a new DB_AA. > >Jakub > >-----Original Message----- >From: apc...@li... >[mailto:apc...@li...] On Behalf Of Mitra >Sent: Tuesday, February 25, 2003 4:56 AM >To: Jakub Adamek; apc...@so... >Subject: RE: [Apc-aa-coders] getDB and freeDB > >Jakub, Honza > >Are we happy with the way I'm suggesting to do this ? > >- Mitra > > >At 9:03 AM +1100 18/2/03, Mitra wrote: > >>You could be correct, I'm not sure if PHP caches connections. >> > >What I KNOW to be bad is using $db, $db2, and $db3 because if in the >middle of using $db to fetch records, then you use a function call >(for example to turn and id into a name) and this uses the same $db >then you break things. Its a recipe for bugs. > > >So I see two solutiosn > > >1: $db = new DB_AA() ; use the $db ; > >or > >2: $db = getDB; use the $db ; freeDB($db) > > >Actually, I can't see how #1 (or the current way of doing things) >can reuse database connections, because how does PHP know when >you've finished with the SELECT? > > >yes - there could be a problem with "return" without freeing the db, >but I'd rather have an occasional inefficiency, than a big problem >with possible bugs. I'm not making any mass changes, just changing >the code as I work on it, so I think it will be easy to do it >carefully. > > >- Mitra > > > >At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: > >>Mitra, >> >>the PHPlib approach of having the DB connection and recordset in one >>class is a bit strange. The result is, we should create a new recordset >>DB_AA for each SELECT query. The current approach of using one recordset >>everywhere is perhaps caused by the name DB_AA which looks like database >>and usually only one database is used. It is surely wrong. >> >>I am not sure, but my idea was that the persistent connections are kept >>by PHP and not by individual scripts and thus creating a new DB_AA would >>waste no time as it uses always only finds a persisten connection? It >>this is the case, getDB and freeDB are not needed because they only >>duplicate this behavior. >> >>One more remark: Your approach seems to me a bit uncovenient. The >>problem is you must call freeDB() every time you exit any function. >>Surely somebody will forget to do so at least in some places where he or >she uses "return". In C++ such things are solved by constructors and >destructors, but PHP has no destructors. On the other hand this will >perhaps do no much damage as the not-freed DBs will be closed as the >script finishes. > >Jakub > >> -----Original Message----- >> From: apc...@li... >> [mailto:apc...@li...] On Behalf Of Mitra > > Sent: Sunday, February 16, 2003 10:56 AM >> To: apc...@so... >> Subject: [Apc-aa-coders] getDB and freeDB >> >> >> One change of note is to add functions getDB and freeDB so that there >> is no longer the risk of one operation mucking up an in-process DB >> action. >> >> Basically instead of trying to decide whether to use globals $db $db2 >> or $db3 instead just go >> >> >> $db = getDB() >> $db->normal db ops >> freeDB($db) >> >> The system keeps an array of unused $db's so that we still get the >> advantages of keeping connections open. >> >> I have NOT incorporated this into the existing code, - since to do so > > > would inevitably involve making one or more mistakes that broke > > > something!, but I will do whenever I'm working on something. > > > > > > - Mitra > > > > > > -- > > > Mitra Technology Consulting - www.mitra.biz - >> mi...@mi... 02-6684-8096 or 0414-648-0722 >> >> Life is a Mystery to be Lived, not a Problem to be Solved >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Apc-aa-coders mailing list >> Apc...@li... > > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > > > > > >-- > >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved > > > >-- >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Jakub A. <jak...@se...> - 2003-03-04 12:34:06
|
Mitra, I understand you fully. But my idea is you don't need to create a database pool if it takes no time and resources to create a new connection. Just delete or "global $db" and each function creates its own connection (or reuses a persistent one). But it would be necessary to measure whether this approach will or won't take too much time or memory. Jakub -----Original Message----- From: apc...@li... [mailto:apc...@li...] On Behalf Of Mitra Sent: Monday, March 03, 2003 11:16 PM To: Jakub Adamek; apc...@so... Subject: RE: [Apc-aa-coders] getDB and freeDB Jakub The issue is NOT about creating and destroying variables. What we are trying to achieve is to make sure database connections are cached. if you use local variables - e.g. $db = new DB_AA - then I believe the variable will be destroyed and the database connection dropped at the end of the function. If you use global variables - i.e. global $db - then you share the database connection, but there is a significant risk that an inner function will try and use a database connection still being used at the outer level. getDB and freeDB use a database pool, look at the definitions in util.php3 to see how, a function grabs a free DB_AA and then releases it when finished. That way only the minimum needed number of DB_AA (and Database connections) get created. I'm making assumptions about how PHP manages its database connections, which is why I'm asking this question, in case either of you have more information. - Mitra At 11:35 AM +0100 3/3/03, Jakub Adamek wrote: I am not sure when PHP frees variables, perhaps on leaving a function, surely not later than on finishing the script. This way it knows you finished your SELECT. My suggestion is not to use "global $db" but "$db = new DB_AA" which should be sufficient. Perhaps you could measure how much time (if any) it takes to create a new DB_AA. Jakub -----Original Message----- From: apc...@li... [mailto:apc...@li...] On Behalf Of Mitra Sent: Tuesday, February 25, 2003 4:56 AM To: Jakub Adamek; apc...@so... Subject: RE: [Apc-aa-coders] getDB and freeDB Jakub, Honza Are we happy with the way I'm suggesting to do this ? - Mitra At 9:03 AM +1100 18/2/03, Mitra wrote: You could be correct, I'm not sure if PHP caches connections. What I KNOW to be bad is using $db, $db2, and $db3 because if in the middle of using $db to fetch records, then you use a function call (for example to turn and id into a name) and this uses the same $db then you break things. Its a recipe for bugs. So I see two solutiosn 1: $db = new DB_AA() ; use the $db ; or 2: $db = getDB; use the $db ; freeDB($db) Actually, I can't see how #1 (or the current way of doing things) can reuse database connections, because how does PHP know when you've finished with the SELECT? yes - there could be a problem with "return" without freeing the db, but I'd rather have an occasional inefficiency, than a big problem with possible bugs. I'm not making any mass changes, just changing the code as I work on it, so I think it will be easy to do it carefully. - Mitra At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: Mitra, the PHPlib approach of having the DB connection and recordset in one class is a bit strange. The result is, we should create a new recordset DB_AA for each SELECT query. The current approach of using one recordset everywhere is perhaps caused by the name DB_AA which looks like database and usually only one database is used. It is surely wrong. I am not sure, but my idea was that the persistent connections are kept by PHP and not by individual scripts and thus creating a new DB_AA would waste no time as it uses always only finds a persisten connection? It this is the case, getDB and freeDB are not needed because they only duplicate this behavior. One more remark: Your approach seems to me a bit uncovenient. The problem is you must call freeDB() every time you exit any function. Surely somebody will forget to do so at least in some places where he or she uses "return". In C++ such things are solved by constructors and destructors, but PHP has no destructors. On the other hand this will perhaps do no much damage as the not-freed DBs will be closed as the script finishes. Jakub > -----Original Message----- > From: apc...@li... > [mailto:apc...@li...] On Behalf Of Mitra > Sent: Sunday, February 16, 2003 10:56 AM > To: apc...@so... > Subject: [Apc-aa-coders] getDB and freeDB > > > One change of note is to add functions getDB and freeDB so that there > is no longer the risk of one operation mucking up an in-process DB > action. > > Basically instead of trying to decide whether to use globals $db $db2 > or $db3 instead just go > > > $db = getDB() > $db->normal db ops > freeDB($db) > > The system keeps an array of unused $db's so that we still get the > advantages of keeping connections open. > > I have NOT incorporated this into the existing code, - since to do so > would inevitably involve making one or more mistakes that broke > something!, but I will do whenever I'm working on something. > > - Mitra > > -- > Mitra Technology Consulting - www.mitra.biz - > mi...@mi... 02-6684-8096 or 0414-648-0722 > > Life is a Mystery to be Lived, not a Problem to be Solved > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Apc-aa-coders mailing list > Apc...@li... > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
|
From: Mitra <mi...@ea...> - 2003-03-04 21:41:48
|
OK - now I understand your point. I think that creating connections DOES take resources, especially if the database is remote to the web server, or has a slow authentication process. - Mitra At 1:33 PM +0100 4/3/03, Jakub Adamek wrote: >Mitra, > >I understand you fully. But my idea is you don't need to create a >database pool if it takes no time and resources to create a new >connection. Just delete or "global $db" and each function creates >its own connection (or reuses a persistent one). But it would be >necessary to measure whether this approach will or won't take too >much time or memory. > >Jakub > >-----Original Message----- >From: apc...@li... >[mailto:apc...@li...] On Behalf Of Mitra >Sent: Monday, March 03, 2003 11:16 PM >To: Jakub Adamek; apc...@so... >Subject: RE: [Apc-aa-coders] getDB and freeDB > >Jakub > >The issue is NOT about creating and destroying variables. > >What we are trying to achieve is to make sure database connections are cached. > >if you use local variables - e.g. $db = new DB_AA - then I believe >the variable will be destroyed and the database connection dropped >at the end of the function. > >If you use global variables - i.e. global $db - then you share the >database connection, but there is a significant risk that an inner >function will try and use a database connection still being used at >the outer level. > >getDB and freeDB use a database pool, look at the definitions in >util.php3 to see how, a function grabs a free DB_AA and then >releases it when finished. That way only the minimum needed number >of DB_AA (and Database connections) get created. > >I'm making assumptions about how PHP manages its database >connections, which is why I'm asking this question, in case either >of you have more information. > >- Mitra > > >At 11:35 AM +0100 3/3/03, Jakub Adamek wrote: > >>I am not sure when PHP frees variables, perhaps on leaving a >>function, surely not later than on finishing the script. This way >>it knows you finished your SELECT. My suggestion is not to use >>"global $db" but "$db = new DB_AA" which should be sufficient. >>Perhaps you could measure how much time (if any) it takes to create >>a new DB_AA. >> > > >Jakub > >-----Original Message----- >From: apc...@li... >[mailto:apc...@li...] On Behalf Of Mitra >Sent: Tuesday, February 25, 2003 4:56 AM >To: Jakub Adamek; apc...@so... >Subject: RE: [Apc-aa-coders] getDB and freeDB > >Jakub, Honza > > >Are we happy with the way I'm suggesting to do this ? > > >- Mitra > > > >At 9:03 AM +1100 18/2/03, Mitra wrote: > >>You could be correct, I'm not sure if PHP caches connections. >> > >What I KNOW to be bad is using $db, $db2, and $db3 because if in the >middle of using $db to fetch records, then you use a function call >(for example to turn and id into a name) and this uses the same $db >then you break things. Its a recipe for bugs. > > >So I see two solutiosn > > >1: $db = new DB_AA() ; use the $db ; > >or > >2: $db = getDB; use the $db ; freeDB($db) > > >Actually, I can't see how #1 (or the current way of doing things) >can reuse database connections, because how does PHP know when >you've finished with the SELECT? > > >yes - there could be a problem with "return" without freeing the db, >but I'd rather have an occasional inefficiency, than a big problem >with possible bugs. I'm not making any mass changes, just changing >the code as I work on it, so I think it will be easy to do it >carefully. > > >- Mitra > > > >At 8:56 PM +0100 17/2/03, Jakub Adamek wrote: > >>Mitra, >> >>the PHPlib approach of having the DB connection and recordset in one >>class is a bit strange. The result is, we should create a new recordset >>DB_AA for each SELECT query. The current approach of using one recordset >>everywhere is perhaps caused by the name DB_AA which looks like database >>and usually only one database is used. It is surely wrong. >> >>I am not sure, but my idea was that the persistent connections are kept >>by PHP and not by individual scripts and thus creating a new DB_AA would >>waste no time as it uses always only finds a persisten connection? It >>this is the case, getDB and freeDB are not needed because they only >>duplicate this behavior. >> >>One more remark: Your approach seems to me a bit uncovenient. The >>problem is you must call freeDB() every time you exit any function. >>Surely somebody will forget to do so at least in some places where he or >> >she uses "return". In C++ such things are solved by constructors and > >destructors, but PHP has no destructors. On the other hand this will > >perhaps do no much damage as the not-freed DBs will be closed as the >script finishes. > >Jakub > >> -----Original Message----- >> From: apc...@li... >> [mailto:apc...@li...] On Behalf Of Mitra > > > Sent: Sunday, February 16, 2003 10:56 AM >> To: apc...@so... >> Subject: [Apc-aa-coders] getDB and freeDB >> >> >> One change of note is to add functions getDB and freeDB so that there >> is no longer the risk of one operation mucking up an in-process DB >> action. >> >> Basically instead of trying to decide whether to use globals $db $db2 >> or $db3 instead just go >> >> >> $db = getDB() >> $db->normal db ops >> freeDB($db) >> >> The system keeps an array of unused $db's so that we still get the >> advantages of keeping connections open. >> >> I have NOT incorporated this into the existing code, - since to do so > > > would inevitably involve making one or more mistakes that broke > > > something!, but I will do whenever I'm working on something. > > > > > > - Mitra > > > > > > -- > > > Mitra Technology Consulting - www.mitra.biz - >> mi...@mi... 02-6684-8096 or 0414-648-0722 >> >> Life is a Mystery to be Lived, not a Problem to be Solved >> >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >> http://thinkgeek.com/sf >> _______________________________________________ >> Apc-aa-coders mailing list >> Apc...@li... > > > https://lists.sourceforge.net/lists/listinfo/apc-aa-coders > > > > > > >-- > >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved > > > >-- > >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved > > > >-- >Mitra Technology Consulting - www.mitra.biz - mi...@mi... >02-6684-8096 or 0414-648-0722 > >Life is a Mystery to be Lived, not a Problem to be Solved -- Mitra Technology Consulting - www.mitra.biz - mi...@mi... 02-6684-8096 or 0414-648-0722 Life is a Mystery to be Lived, not a Problem to be Solved |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X