Datebase close() function

[eluser]Randy Casburn[/eluser]
OK. Then we're really are left with only two possibilities.

1) if (is_resource($this->conn_id) OR is_object($this->conn_id))

This line of code is not evaluating as expected - the resource_id is broken for some strange reason

---
As you can see, this would result in not getting an error returned since the driver sends the close to mysql with @mysql_close() hence thwarting your error condition. Also, it would result in the resource_id being set to false since that is outside the conditional logic of the test for is_resource.

Make sense?

----
or

2) We have a scope problem with $this

this is highly unlikely as this would surely throw an error complaining that you are calling a method of a non-object.

Hope this all has helped.

Randy

[eluser]haraldo[/eluser]
Thanks Randy,

Why would it make a difference where i call mysql_close( conn_id ) from, as long as i always pass it a valid connection id?

I call mysql_close in my function and it works.

Or i call it through $this->oDB->close() and it goes all the way through to the mysql_driver _close function but the mysql_close here doesn't close it.

I can then go on further and into my controller and add records even tho i've supposidly closed the connection! Really iritating. I may just leave the mysql_close in my code.

p.s. the resource is always returning true and even without the @ infront of mysql_close i get no errors. Chears

[eluser]haraldo[/eluser]
Oh god,

Go figure this. It ultimately does close it.

However the 2 scenarios we have are that when i close it in my function using mysql_close() it works instantly. No more records get inserted subsequently.

When you dish the responsability out to another class to close the connection e.g. $this->oDB->close() .

It doesn't close it until the script finishes its full execution.

Found out by fluke when i got one of my controllers to execute the same insert using the same db object. First time through 2 records went in ( Hook and controller inserts ). on refresh i get a 500 internal server error on the controller one because the connection does not exist anymore.

Well you learn something new every so often.

Thanks for your time - i feel i wasted it somewhat.

[eluser]Randy Casburn[/eluser]
No waste of time. This is enlightening...and I'm not sure it is the expected behaviour. I bet I've run up against this three or four times and never realized what was happening. But I fixed it by working around the "fluke" without realizing it.

This seems really odd:

However the 2 scenarios we have are that when i close it in my function using mysql_close() it works instantly. No more records get inserted subsequently.

When you dish the responsibility out to another class to close the connection e.g. $this->oDB->close() .

It doesn’t close it until the script finishes its full execution.

Try this and see what happens:
Switch up your closeDBConn method to:

Code:

protected function _closeDBConn() {
        
        //$this->oDB->close();
        $this->oDB->conn_id = NULL;
    }

and then run your second call to recordVisit() method and see if your second row is written to the table.

Randy

[eluser]Frank Berger[/eluser]
the mysql_close() function in php does not call close on the mysql database, it just registers the connection as deletable inside the Zend engine. There are much more variables at work, like a pconnection, shared connections, running as cgi, running as isapi, running as apache-module, transactions, locks, late inserts and so on and so on, than for the php-part alone to decide if it actually can close the connection, or if it will be re-used later.

If you depend on closing the db-connection inside your php script for some reason, use the 'set null' method above. if you depend on closing the connection from a system/web-server point of view, rather have your php process run as cgi than as embedded module in apache.

The different results above might very well be connected to apache-childs being at the beginning or respectively at the end of their live cycles, I would have seen weirder stuff in the past.

what mysql_close (the native php function) essentially says is 'I am finished, from my point of view you (zend, webserver, dbserver, dbengine) can close the connection', therefor i wouldn't hang up too much on if your script at runtime actually still has the database connection or not, as long as it called db-close at some point in time. Although you shouldn't expect having a db connection after calling close either, as all the other parties involved might very well say 'yep, no need anymore'.

Frank

[eluser]haraldo[/eluser]
Thanks Frank thats good to know. Doesn't explain why when i run mysql_close() at the top level, no further inserts get into the db, but by using codeigniter to close the connection ( which uses the same mysql_close function just a few levels down ) the subsequent inserts get put in the db right up until the end of the script execution. The behaviour just doesn't seem right.

[eluser]Randy Casburn[/eluser]
[quote author="haraldo" date="1225650677"]Thanks Frank thats good to know. Doesn't explain why when i run mysql_close() at the top level, no further inserts get into the db, but by using codeigniter to close the connection ( which uses the same mysql_close function just a few levels down ) the subsequent inserts get put in the db right up until the end of the script execution. The behaviour just doesn't seem right.[/quote]

@Frank, We appreciate your wisdom here. Unfortunately, the evidence indicated in the dichotomy Haraldo describes above makes your hypothesis inaccuate. In fact, that is exactly where I was going at first with this until Haraldo exposed the problem as clearly as it exists.

@Haraldo - have you found to time to try setting the conn_id=NULL as I suggested above rather than using the close function?

I would think that should give you the results you expect as Frank mentions. It would also confirm:

A) When CI object model issues the mysql_close() statement it is not executed until script closure (this would confirm your suspicion)

BUT

B) When issued directly (non object method), or by setting the conn_id NULL, the effect is immediate.

-------

B above gives us two accepted, best practice, ways to resolve the issue. These fixes also allow us to confirmi that CI, and not the Zend engine or MySQL is the culprit since they both invoke a MySQL solution through the Zend engine to fix the problem.

@Frank - this is why I agree with Haraldo here.

Randy

[eluser]haraldo[/eluser]
The second record still gets written to the db after setting $this->oDB->conn_id = NULL. Infact if you close the connection through codeigniter and then print_r the db object ( in my case $this->oDB ) it shows the conn_id as null and the records still gets written in.

As it happens i've gone with the codeigniter way as i'm convinced now the connection is closed, be it at the end of execition.

So i'm none the wiser as to why this occurs but it does sound like the actually connection is dropped towards the end of execution rather than when i actually call the function to close it. This may be a php object thing thats messing with it ( the fact that i'm relying on another object to close the connection ). Its a little strange but i can live with it!

[eluser]Randy Casburn[/eluser]
Ok...I'll put up some code and step through it with my debugger one line at a time while I watch the connection, I'll also be able to execute calls to mysql through the live CI environment that is running to determine if the connection is in fact alive, or if it is closed and a new connection is being opened instead (as I suspect).

I'll let you know as I get time to do this.

Randy

[eluser]Randy Casburn[/eluser]
@haraldo - You know, I just thought of something. What is the content of your autoload.php file line for your libraries autoload? Does it contain array('database'); ?

Randy