Subject | Re: [firebird-support] Re: Firebird Logging |
---|---|
Author | Ann Harrison |
Post date | 2013-03-28T16:23:18Z |
On Thu, Mar 28, 2013 at 10:11 AM, sean_ohare@... <sean_ohare@...
inserted records, either the transaction that inserted the records is not
committing or you are using an old transaction for your reads. The only
answer to the first problem is to commit transactions that insert records
whenever the inserts have created a consistent state of the database.
There are a couple of ways to handle reading from "old" transactions. By
default, Firebird runs in a mode where reads are stable - you don't see
changes that were committed after your transactions starts. Firebird does
support "read committed" isolation mode in which you can read changes that
were committed after your transaction starts. Read Committed transactions
do not provide a stable view of data - a single select statements may
return different results if it is run multiple times. That's bad for
two-step operations (e.g. percent of total), but means that you don't need
to committed read-only transactions as often.
Ideally, if you don't need stability across statements, don't block them
together in a single transaction. In a less than ideal world, create a
read-only read-committed transaction so you can see changes as they are
committed.
Good luck,
Ann
[Non-text portions of this message have been removed]
> wrote:Sorry ...
>
>
> We are not the original developer of the application, but have now been
> given the task of maintaining/debugging this 750,000 + lines of Delphi 7
> code.
> Does FireBird support isolation levels ? There are a number ofNo, Firebird does not allow dirty reads. If you are not seeing newly
> transactions that are waiting for locks to be release, which can be solved
> by changing the isolation level to dirty/uncommitted reads. These are for
> read only transactions.
>
>
inserted records, either the transaction that inserted the records is not
committing or you are using an old transaction for your reads. The only
answer to the first problem is to commit transactions that insert records
whenever the inserts have created a consistent state of the database.
There are a couple of ways to handle reading from "old" transactions. By
default, Firebird runs in a mode where reads are stable - you don't see
changes that were committed after your transactions starts. Firebird does
support "read committed" isolation mode in which you can read changes that
were committed after your transaction starts. Read Committed transactions
do not provide a stable view of data - a single select statements may
return different results if it is run multiple times. That's bad for
two-step operations (e.g. percent of total), but means that you don't need
to committed read-only transactions as often.
Ideally, if you don't need stability across statements, don't block them
together in a single transaction. In a less than ideal world, create a
read-only read-committed transaction so you can see changes as they are
committed.
Good luck,
Ann
[Non-text portions of this message have been removed]