ibase_close not working as expected

[haanerg]

It looks like ibase_close noes not work as expected, at least if the docs are to be believed. Closing a connection doesn't work for us with PHP7.4.3 and version 1.1.1 of the driver. Other combinations tested yields the same result. There also seems to be a mismatch between the docs and the test case (ibase_close_001.phpt).

If we have a look at the test case:

--TEST--
ibase_close(): Basic test
--SKIPIF--
<?php include("skipif.inc"); ?>
--FILE--
<?php

require("interbase.inc");

$x = ibase_connect($test_base);
var_dump(ibase_close($x));
var_dump(ibase_close($x));
var_dump(ibase_close());
var_dump(ibase_close('foo'));

?>
--EXPECTF--
bool(true)
bool(true)
bool(true)

Warning: ibase_close() expects parameter 1 to be resource, string given in %s on line %d
NULL

If the connection ($x) is truly closed, the second and third call to ibase_close should return false. However, it seems like calling ibase_close($x) does not close the connection. Calling ibase_close() without a resource seems to close all connections, which is ok but not documented.

[mortzdk]

So it looks like if ibase_close is called without arguments, only the latest resource (default_link) will be closed, after which any further calls to ibase_close without arguments will result in the function returning false. https://github.com/FirebirdSQL/php-firebird/blob/master/interbase.c#L1060

Whenever ibase_close is called with a connection, the function will always return true.

We end up having problems because of the behavior of ibase_close. (The behaviour is not the same in previous versions - we tested it in PHP 7.0).

Our test does the following:

1. We select a value.
2. We update the value in a transaction and commit the change.
3. We select the value again (here we get the old value, since the query is performed on the connection which is in a state prior to the transaction just performed - as far as I understand)
4. Then we close the connection
5. We do a select on the closed connection (Which works? - But still yields the old value)
6. We select the value again using a newly created connection (This is now expected to be in a state after the transaction performed above) This is the part that fails with the new firebird driver, while it works in the PHP 7.0 CORE version, hence we get the old value rather than the updated one.
7. We create a new transaction and fetch the value, which results in the updated value as expected.

$connection = ibase_connect($database, $username, $password);

//INITIAL SELECT
$stmt = ibase_prepare($connection, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
echo "PRE UPDATE\n";
var_dump($data);
ibase_free_result($res);
ibase_free_query($stmt);

        
//TRANSACTION UDPATE AND SELECT
IBASE_DEFAULT;
$transaction = ibase_trans(IBASE_DEFAULT, $connection);
$stmt = ibase_prepare($connection, $transaction,  "UPDATE \"EVENT\" SET ARRANGOR_ID = ? WHERE EVENT_NO = ?");
ibase_execute($stmt, $newID, $eventNo);
ibase_free_query($stmt);

$stmt = ibase_prepare($connection, $transaction, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
ibase_free_result($res);
ibase_free_query($stmt);


echo "IN TRANSACTION\n";
var_dump($data);

ibase_commit($transaction);


//AFTER TRANSACTION
$stmt = ibase_prepare($connection, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
ibase_free_result($res);
ibase_free_query($stmt);
        
echo "AFTER TRANSACTION\n";
var_dump($data);

//CLOSE CONNECTION 
//        ibase_close();
ibase_close($connection);


//        TEST CLOSED CONNECTION WORKING
$stmt = ibase_prepare($connection, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
ibase_free_result($res);
        
echo "AFTER CLOSE\n";
var_dump($data);


$newConnection = ibase_connect($database, $username, $password);

//AFTER RECONNECT
$stmt = ibase_prepare($newConnection, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
echo "AFTER RECONNECT \n";
var_dump($data);
ibase_free_result($res);




        
//SELECT IN NEW TRANSACTION 
$transaction = ibase_trans(IBASE_DEFAULT, $newConnection);
$stmt = ibase_prepare($newConnection, $transaction, "SELECT ARRANGOR_ID FROM \"EVENT\" WHERE EVENT_NO = ?");
$res = ibase_execute($stmt, $eventNo);
$data = ibase_fetch_assoc($res);
ibase_free_result($res);

echo "IN NEW TRANSACTION\n";
var_dump($data);

ibase_commit($transaction);

[mlazdans]

@MartinKoeditz did you got a chance to check this? Any thoughts? There is something wrong with closing connections indeed. It seems it is related to how (in the past?) PHP was handling ref counts.

I did not check @mortzdk example because it is incomplete.

[mlazdans]

There are too many references laying around. These is a special check for that at ibase_close():

php-firebird/interbase.c

Lines 1204 to 1209 in 5c7e20d

	/* we have at least 3 additional references to this resource ??? */
	if (GC_REFCOUNT(link_res) < 4) {
	zend_list_close(link_res);
	} else {
	zend_list_delete(link_res);
	}

At least one ref is added to internal connection list.

[mlazdans]

I feel like touching and fixing this will definitely break some old apps.

[mlazdans]

Currently ibase_close() does not close anything. It just decreases refcount and if it reaches 3 and just then do actual close. 3 is reached due some kind of internals, not sure if this is even needed or works correctly.

So if you do:

$x = ibase_connect("db.fdb", "sysdba", "masterkey");
var_dump(ibase_close($x));
var_dump(ibase_close($x)); // You have to do close two times in current implementation
var_dump(ibase_query($x, 'SELECT * FROM RDB$DATABASE')); // now it fails

So if you do:

$x = ibase_connect("db.fdb", "sysdba", "masterkey");
$y = $x; // this increases refcount
var_dump(ibase_close($x));
var_dump(ibase_close($x)); // You have to do close two times in current implementation
var_dump(ibase_close($x)); // And you have to do another one to erase ref to $y
var_dump(ibase_query($x, 'SELECT * FROM RDB$DATABASE')); // now it fails

As I mentioned before fixing this may break some apps but in my opinion this is wrong and should be fixed anyways.

[mlazdans]

I implemented immediate detach from database on ibase_close(). Calling multiple ibase_close() on same link just does not make any sense indeed! We can put this behaviour under a flag because it most definitely will break some old code.

Already broke two tests:

• tests/002.phpt
• tests/005.phpt

They kinda assume that this will create two connections:

	$pcon1 = ibase_pconnect($test_base);
	$pcon2 = ibase_pconnect($test_base);

which it does not. This will just reuse existing connection. So ibase_close($pcon1); works but ibase_close($pcon2); - will now fail because essentially $pcon1 == $pcon2.