Re: [PHP4BETA] cvs: /php4/ext/odbc php_odbc.h php_odbc.c

You wrote: >Normally, the user doesn't need to bother with closing connections Unless: A.) you're dealing with a system that is licensed for x connections and you want to close as quickly as possible to allow other concurrent users while the PHP script is processing the data (or waiting for something slow) B.) you want to make sure no matter what ODBC thinks it is doing that a transaction has been committed C.) you're getting data from more than one database, or use different connection parameters, and you must save licenses, or resources, or simply want to be clear about when access to one database is finished I have scripts that have many steps in conditional switches, and I am very happy to have points where I know that no matter how execution got there all connections should be closed, ready for a different part of the script. odbc_close() has been here for a while, and it should keep working. odbc_close_all() can be a more efficient implementation. The problem with your reference counting as I see it is that if a user forgets a result, either because he is not a good programmer, or because of an exception in execution, then the connection stays open. That is not good. If someone knows there is a potential for exceptions, he should be able to force any connection to close with great certainty. For some sites a connection is expensive. If the reference count is not zero then the connection would not close, right? I must close connections to allow concurrent access. I don't want to start keeping track of results for the new(!) PHP4. What you have started to implement would force me to make sure all results have been freed on any path of execution. I need to be able to close a connection and know for sure it has been closed. This has worked fine in PHP3 and there should be no reason to change the logic now. >But with Zend's reference mechanism exists a very simple way to have >connections and results destroyed in the right order automatically on >request shutdown. Reference counters (neat as they are) are not the best answer for connection/result which should be dealt with as containment like connection/statement. Create results if you have a connection, delete them when the connection goes away. It must be contained, and that does not need reference counting, which is for out-of containment situations. >But with Zend's reference mechanism exists a very simple way to have >connections and results destroyed in the right order automatically on >request shutdown. Did you think through all that? Whatever your wrote so far still crashes for me. Before I started looking at the source code I had considered PHP4 non-working, and I got a similar feeling from other Win32 and ODBC users. >But with Zend's reference mechanism exists a very simple way to have >connections and results destroyed in the right order automatically on >request shutdown. Are you sure? Did you think that through? Let's say there are result a,b,c,d, all from connection z. Connection z should have a reference count in the list of what, 4 or 5. When traversing the list it is time to delete z will it or won't it be deleted? If it will, then results may still exist. If it won't, then what, will it be revisited later on? Pretty nifty algorithm for something that looks more like a patchwork. Impressive patchwork I have to admit, but not exactly the world's most theoretically backed architecture. There are other things that matter than request shutdown. Some people want to do a lot of stuff within one script, and what has worked in PHP3 should work in PHP4. >The problem with your code was that it was unnecessary. From your point of view. All my PHP3 scripts crashed until I put that patch in, and other people had similar problems. - Leo Baschy <nirvana@got.net>