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
>