At 07:41 AM 30/12/2007, Edwin Pratomo wrote:

>I've just looked into problem related with DBD::InterBase reported on
>http://rt.cpan.org/Public/Bug/Display.html?id=30812
>which leads to this thread.
>
>it's not about AutoCommit implementation, because DBD::InterBase does hard
>commit, unless the user chooses to do soft commit.
>a db connection with a single transaction doing only a single select will
>exhibit that stuck OIT behaviour. you can try api3.c example included in
>Firebird distribution to see this.
>
>attached is a simple C program (based on api3.c) and a bash script which
>produces the following result:
>
>[edwin@localhost stuck-oit]$ ./stuck-oit.sh
> Oldest transaction 1
> Oldest active 2
> Next transaction 3
> Bumped transaction 1

At this point, transaction #2 is active and is interested in the completed (committed or rolled-back) transaction #1.

>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
>SELECT result: 1
> Oldest transaction 1
> Oldest active 2
> Next transaction 13
> Bumped transaction 1

Transaction #2 is still active, so at least *it* still regards #1 as interesting, so OIT doesn't move. Until Transaction #2 is completed, it remains as the OAT. Now, you have 10 more transactions started. We cannot tell whether any of them is likely to be interested in #2, or in one another.

>this leads me to a question: is this behaviour expected?

Yes.

These figures don't tell anything except that you started 10 transactions while you had the same active read-write transaction hanging about...Oldest Snapshot can give you an indication of whether GC has actually occurred - although, even if GC has occurred, the Oldest Snapshot won't move forward if Oldest Active hasn't changed.

./heLen