If rollback has the same overhead as commit, then there must be
something else going on here, because when I switched it to rollback,
the 10 second delay went away.

Thanks,
- Dave


--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 08:48 PM 5/11/2003 +0000, you wrote:
> >I have an application written in Java which uses IB6 and Firebird
> >InterClient.
> >
> >In the application, there are places where I perform an ad-hoc query
> >and return the results to a GUI. Psuedocode is:
> >
> >{
> > db.beginTran();
> > results = db.exec(selectStatement);
> > db.commitTran();
> >
> > return result;
> >}
> >
> >I put timings around each statement. Getting the results takes about
> >100ms, give or take, but the commit takes 10,000ms (almost exactly)
> >every time. I tried changing the commit to a rollback, and it dropped
> >to <10ms. I have two questions:
> >
> >1) Where is that 10 second commit coming from? Some sort of timeout?
>
> The select is "fast" because the client fetches rows into a client

buffer

> and leaves the rest in the server's cache until it is ready to ask for
> another load of rows. The fetching from the server has to complete

before

> the commit or rollback can complete. You will see this behaviour if

your

> select is operating on a large output set with no WHERE clause to limit
> rows returned. If you tell the transaction to SELECT * FROM TABLE,

then

> that is what it has to do.
>
> >2) Is using rollback a safe/viable work-around for this speed issue?
>
> No. The transaction has to finish its work in either case. Commit has
> less overhead than rollback so, unless you actually have some posted

work

> that you want to roll back, commit is preferable.
>
> heLen