Subject | Re: Prepared statement with transactions leads to a crash in gds32.dll |
---|---|
Author | Stan |
Post date | 2006-11-02T17:08:29Z |
--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:
$res = ibase_execute( $stmt, $entry[0], $entry[1], $entry[2]);
this works with one client, it crashes with more than 1.
the logs from above apear after the lock conflict when I am retrying.
thanks,
stan
>its a typo, it should be:
> At 11:15 AM 2/11/2006, you wrote:
> >Hi All,
> >
> >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?
>
> That's not a lock conflict. It's an unhandled exception.
>
> >
> >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]);
>
> Before probing too deeply, there are only 2 $entry assignments
> 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
$res = ibase_execute( $stmt, $entry[0], $entry[1], $entry[2]);
this works with one client, it crashes with more than 1.
the logs from above apear after the lock conflict when I am retrying.
thanks,
stan
>