Subject | Re: [firebird-support] Prepared statement with transactions leads to a crash in gds32.dll |
---|---|
Author | Helen Borrie |
Post date | 2006-11-02T02:50:42Z |
At 11:15 AM 2/11/2006, you wrote:
here. If the snippet is copied from your actual script, then the
XSQLDA has prepared 3 XSQLVARs and the loop is populating $entries
with only two, with the second probably of the wrong type. (You
repeat the same typo, on the assignment to the second parameter, in
your retry). I suspect that the client is crashing because you
(don't seem to be) intercepting the exceptions in either case.
Just an initial thought on the situation...
./heLen
>Hi All,That's not a lock conflict. It's an unhandled exception.
>
>The following code snippet (php, sorry)
>causes a crash in gds32.dll whenever I have
>a lock-conflict. Debugger is saying that
>the crash is an Access Violation inside
>isc_dsql_execute2().
>
>If I run this code from 1 client, everything
>works, if I run 2, I get a crash every time.
>
>I am using:
>Apache 2.0.54
>PHP 5.1.6 (CGI)
>Windows XP Pro
>Firebird 1.5.3
>
>It works fine if I do NOT use prepared statements.
>
>It works fine if I do not use explicit transaction handling,
>but very slow...
>
>I think that I am doing something stupid when I encounter a
>lock conflict.
>
>In the php logs I get:
>-501 Attempt to reclose a closed cursor
>and
>invalid transaction handle (expecting explicit transaction start)
>
>what am I doing wrong?
>
>also, Why do I ALWAYS get a lock conflict when using prepared
>statements even if I only have 2 concurrent clients?
>Before probing too deeply, there are only 2 $entry assignments
>If do NOT use prepared statements, I rarely get lock-conflicts.
>I tried using COMMITED|REC_VERSION and COMMITED|REC_NO_VERSION,
>exactly the same behavior.
>
>thanks,
>
>stan
>
>
>Code Snippet:
>----------------------------
>
>$db = ibase_connect (...);
>$trans = ibase_trans($db, IBASE_WRITE|IBASE_CONCURRENCY|IBASE_WAIT);
>$stmt = ibase_prepare($trans, "SELECT id FROM GET_ID(?,?,?)");
>
>foreach($entries as $entry){
> $res = ibase_execute( $stmt, $entry[0], $enty[1], $entry[2]);
here. If the snippet is copied from your actual script, then the
XSQLDA has prepared 3 XSQLVARs and the loop is populating $entries
with only two, with the second probably of the wrong type. (You
repeat the same typo, on the assignment to the second parameter, in
your retry). I suspect that the client is crashing because you
(don't seem to be) intercepting the exceptions in either case.
Just an initial thought on the situation...
./heLen