This problem was solved on linux by turning off automatic
sweep (set sweep to 0) and running a "gfix sweep" every
5 minutes.

On windows we are still getting:
deadlock
internal gds software consistency check (error during savepoint
backout (290))

randomly under load even using the same manual sweep method.

any ideas for this issue?

--- In firebird-support@yahoogroups.com, "Stan" <shizius@...> wrote:
>
> I have arrived at these parameters after much testing,
> Some of my requests are meant to deadlock, in which case
> my application decides what to do about it (rollbalck and retry or
> just rollback)
>
> On windows, I got better performance using
> IBASE_COMMITTED|IBASE_REC_NO_VERSION
> instead of IBASE_CONCURRENCY.
>
> I will try IBASE_CONCURRENCT on linux.
>
> I am currently trying FB2.0 RC1 to see if the newer
> garbage-collection policy has an affect on my issue.
>
> thanks,
>
> stan
>
> --- In firebird-support@yahoogroups.com, "Ann W. Harrison"
> <aharrison@> wrote:
> >
> > Stan wrote:
> > >
> > > Read transactions are opened:
> > > ibase_trans(IBASE_READ|IBASE_CONCURRENCY|IBASE_NOWAIT,$dbh);
> >
> > Why no wait? It doesn't make much difference since read
> > transactions don't wait anyway. Generally, no wait is a
> > way to get more deadlocks.
> > >
> > > Write transactions are pened:
> > >
>
ibase_trans(IBASE_WRITE|IBASE_COMMITTED|IBASE_REC_NO_VERSION|IBASE_NOWAIT,
> > > $dbh);
> > >
> > I would recommend using IBASE_CONCURRENCY, particularly for write
> > transactions in order to get a consistent view of data and avoid
> > accidentally contaminating one transaction with part of the work
> > of another. How can that happen. Suppose you've got a table of
> > deposits and a table of withdrawals. Transaction one creates a
> > withdrawal in one table and a corresponding deposit in another,
> > then commits. Transaction two reads the withdrawal table before
> > transaction one changes it, so does not see the withdrawal. But
> > before transaction two can read the deposit table, transaction
> > one makes its changes and commits, so transaction two sees half
> > of the actions of transaction one. That is a bad thing.
> >
> > As far as I know, the purpose of NO_REC_VERSION is to cause
> > deadlock like errors where none are required, I wouldn't use
> > that either.
> >
> > Regards,
> >
> >
> > Ann
> >
>