Subject | First Steps and Transaction Handling |
---|---|
Author | Matthias Hanft |
Post date | 2009-04-30T09:25:15Z |
Hello,
for many years, I just had used self-programmed Delphi clients
to access my FB databases (FB 2.0.3 on Gentoo Linux 2.6.27).
Since I always had kept an eye to transaction handling, my
"gstat -h" always looked perfect like this:
Oldest transaction 4184676
Oldest active 4184677
Oldest snapshot 4184677
Next transaction 4184678
After one access from a Delphi client (open, transaction, query,
commit, close), the figures were incremented by one:
Oldest transaction 4184677
Oldest active 4184678
Oldest snapshot 4184678
Next transaction 4184679
But now, I have begun to access that database from PHP (5.2.9)
(parallel with the Delphi clients from other workstations). And
strange things happen:
After -
- one access from PHP
- and, after that, several accesses from the other Delphi clients,
"gstat -h" looks like this:
Oldest transaction 4184778
Oldest active 4184779
Oldest snapshot 4184779
Next transaction 4184805
Then, after just one more access from PHP, everything is fine
again:
Oldest transaction 4184817
Oldest active 4184818
Oldest snapshot 4184818
Next transaction 4184819
but the game starts over now (incrementing just "Next transaction"
by Delphi accesses until the next PHP access happens). Howcome?
(I'm afraid the "transaction gap" would become bigger and bigger
without limit, if I wouldn't do another PHP access ever. Is this
true?)
In the support mailing list, I was told that PHP uses connection
pooling (can I switch that off? "ibase.allow_persistent = Off"
seems not to be the setting for it), but why do connections have
something to do with transactions?
In this respect, I just don't quite understand the mapping between
PHP and FB transactions fully. (I do with Delphi.) Currently, in
PHO, I'm using
$dbhandle = ibase_connect("host:database", "user", "pass", "latin1", 0, 3);
// does opening a database cause the creation
// of some "implicit" or "default" transaction?
$stmt = "select ID, MODEL from ACCOUNTS where...";
$trans = ibase_trans( IBASE_DEFAULT, $dbhandle );
// no explicit need for ibase_trans? ibase_query seems
// to work without transaction, too
$sth = ibase_query($dbhandle, $stmt);
// some sources tell me to use "$trans" instead of "$dbhandle"
// here, but this does _not_ adjust the transaction counters
// in "gstat -h"!
$row = ibase_fetch_object($sth));
$myresult["ID"]=$row->ID;
$myresult["MODEL"]=$row->MODEL;
ibase_free_result($sth);
ibase_commit($trans);
// any need for committing any "implicit" transaction here?
// ibase_commit(); and/or ibase_commit($dbhandle); ?
ibase_close($dbhandle);
// really closed now? or just put back into some pool?
Is the above code generally correct?
I'd really *love* to see the "gstat -h" transaction counters
always "clean" (Oldest=X, X+1, X+1, Next=X+2) after each PHP
access (as I do after each Delphi access) - is this possible
at all?
Thank you,
-Matt
for many years, I just had used self-programmed Delphi clients
to access my FB databases (FB 2.0.3 on Gentoo Linux 2.6.27).
Since I always had kept an eye to transaction handling, my
"gstat -h" always looked perfect like this:
Oldest transaction 4184676
Oldest active 4184677
Oldest snapshot 4184677
Next transaction 4184678
After one access from a Delphi client (open, transaction, query,
commit, close), the figures were incremented by one:
Oldest transaction 4184677
Oldest active 4184678
Oldest snapshot 4184678
Next transaction 4184679
But now, I have begun to access that database from PHP (5.2.9)
(parallel with the Delphi clients from other workstations). And
strange things happen:
After -
- one access from PHP
- and, after that, several accesses from the other Delphi clients,
"gstat -h" looks like this:
Oldest transaction 4184778
Oldest active 4184779
Oldest snapshot 4184779
Next transaction 4184805
Then, after just one more access from PHP, everything is fine
again:
Oldest transaction 4184817
Oldest active 4184818
Oldest snapshot 4184818
Next transaction 4184819
but the game starts over now (incrementing just "Next transaction"
by Delphi accesses until the next PHP access happens). Howcome?
(I'm afraid the "transaction gap" would become bigger and bigger
without limit, if I wouldn't do another PHP access ever. Is this
true?)
In the support mailing list, I was told that PHP uses connection
pooling (can I switch that off? "ibase.allow_persistent = Off"
seems not to be the setting for it), but why do connections have
something to do with transactions?
In this respect, I just don't quite understand the mapping between
PHP and FB transactions fully. (I do with Delphi.) Currently, in
PHO, I'm using
$dbhandle = ibase_connect("host:database", "user", "pass", "latin1", 0, 3);
// does opening a database cause the creation
// of some "implicit" or "default" transaction?
$stmt = "select ID, MODEL from ACCOUNTS where...";
$trans = ibase_trans( IBASE_DEFAULT, $dbhandle );
// no explicit need for ibase_trans? ibase_query seems
// to work without transaction, too
$sth = ibase_query($dbhandle, $stmt);
// some sources tell me to use "$trans" instead of "$dbhandle"
// here, but this does _not_ adjust the transaction counters
// in "gstat -h"!
$row = ibase_fetch_object($sth));
$myresult["ID"]=$row->ID;
$myresult["MODEL"]=$row->MODEL;
ibase_free_result($sth);
ibase_commit($trans);
// any need for committing any "implicit" transaction here?
// ibase_commit(); and/or ibase_commit($dbhandle); ?
ibase_close($dbhandle);
// really closed now? or just put back into some pool?
Is the above code generally correct?
I'd really *love* to see the "gstat -h" transaction counters
always "clean" (Oldest=X, X+1, X+1, Next=X+2) after each PHP
access (as I do after each Delphi access) - is this possible
at all?
Thank you,
-Matt