Subject Re: [ib-support] Survival of Prepared state was Re: just if you are curious
Author Kenneth Foo

My mistake...the JayBird DOES support commit retaining.....but only at the
lowest (FB API) level.
The JDBC functions do not use them, as I see this code somewhere
in a file called Seems like it's hardcoded.

public boolean supportsOpenStatementsAcrossCommit() throws SQLException
return false;//commit retaining only.

AFAIK, JDBC does not have a "CommitRetaining" function. (Neither does
if I understand correctly). A connection url switch to toggle commit
retaining function
might be useful in this case, since I suspect it could help out with
performance especially
if we're using some O/R mapping tool...

I'm cross-posting this to Firebird-java, as it seems to be more relevant


----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <>
Sent: Sunday, February 23, 2003 10:38 PM
Subject: [ib-support] Survival of Prepared state was Re: just if you are

> >On Saturday 22 February 2003 18:33, you wrote:
> >
> >Hi,
> >
> > > If I understand correctly, the JayBird driver doesn't allow prepared
> > > statements to persist beyond a commited transaction.
> At 10:42 AM 23/02/2003 +0000, Phil Shrimpton wrote:
> >No 'component' set allows this, as FB does not allow this. Basically,
> >everything in FB is only valid within the context of a transaction, when
> >transaction is closed (committed or rolledback), everything belonging to
> >transaction becomes invalid.
> Indeed FB does allow this. Commit with retain (implemented in Delphi
> components as CommitRetaining) opens a new transaction after committing,
> using the same transaction context as the one just committed. Anything
> prepared in that transaction remains prepared in the API structure that is
> returned.
> Does the Jaybird driver not support CommitRetaining?
> In fact, all data access components I have used with Fb/IB support keeping
> statements prepared until explicitly unprepared (by deallocating the
> statement handle). IB Objects components certainly support it, even if
> API doesn't. The original "Prepare" causes a chain of events that includes
> creation of a persistent client-side structure (Params[]), which is not
> disposed of unless the output structure of the statement is altered. So,
> you can call Commit on the transaction, apply a new set of values to input
> parameters, and go again, without triggering off the unprepare/prepare
> cycle.
> Maybe statement handles are not as tightly bound to transactions as you
> suppose. It's certainly true that a statement handle can't be allocated
> except within an existing transaction context. But maybe there is some
> flag there that lets the programmer decide whether to hold or release the
> statement handle on a hard commit/rollback...
> heLen
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to