long running transaction and garbage collection [CORE2127]

[firebird-automations]

Submitted by: @livius2

Now long running transactions stop garbage collection
Firebird come from Interbase and i suppose the same functionallity can be implemented in Firebird.
Now Interbase have not problem with long running transactions and it not stop garbage collection

Please implement some mechanism to fix this problem in Firebird

[firebird-automations]

Commented by: @hvlad

> Now Interbase have not problem with long running transactions and it not stop garbage collection

Really ?

[firebird-automations]

Commented by: @pcisar

I think he's referring to old feature that read-only transactions never block GC, which was "discovered" by IB marketing and advertised some time ago (IB 7.0 or 7.5? don't remember) as BIG NEW feature, while it was always there. This could be closed as Won't Fix, thought.

[firebird-automations]

Commented by: @hvlad

Pavel, i have the same guess ;) But... i want to hear what Karol refers to ;)

[firebird-automations]

Commented by: @livius2

I have this confirmed by e.g. Craig Stuntz
look at
"Hidden transaction when connect to firebird with Borland dbExress driver like dbexpint.dll .."
at
embarcadero.public.delphi.database.dbexpress

look at this situation (my sample):

I.
1. start transaction A
2. then start transaction B
3. transaction A update record in table A
4. transaction B update record in table B
5. transaction B commit

and in this situation garbage collector should remove record version in table B
but now it do this not becaouse it work only on older active transaction ID and only this records remove
which are older then oldest active transaction

II. more complex sample
1. start transaction A1
2. then start transaction A2
3. transaction A1 update record no. 1 in table A
4. transaction A2 update record no. 2 in table A
5. transaction A2 commit

and in this situation garbage collector should remove record version of record 2 in table A

III. much more complex sample
1. start transaction A12
2. then start transaction A13
3. transaction A12 update record no. 1 and 2 in table A
4. transaction A13 update record no. 1 and 3 in table A
5. transaction A13 commit

and in this situation garbage collector should remove record version of record 3 in table A

i do not know if this is possible but may by is :)

[firebird-automations]

Commented by: @hvlad

--------
look at this situation (my sample):

I.
1. start transaction A
2. then start transaction B
3. transaction A update record in table A
4. transaction B update record in table B
5. transaction B commit

and in this situation garbage collector should remove record version in table B
-------

No, because txA can read table B and must see old record version

---
but now it do this not becaouse it work only on older active transaction ID and only this records remove
which are older then oldest active transaction
---
Of course. Else transaction A will not see record in table B at all

Other examples also WRONG.

But it have no answer on my question :

---
> Now Interbase have not problem with long running transactions and it not stop garbage collection

Really ?
---

[firebird-automations]

Commented by: @hvlad

---
I have this confirmed by e.g. Craig Stuntz
look at
"Hidden transaction when connect to firebird with Borland dbExress driver like dbexpint.dll .."
at
embarcadero.public.delphi.database.dbexpress
---
a) I see no your examples there
b) Craig said : Long-running transactions *do not necessarily* stop garbage collection or degrade performance on InterBase

and this is correct.
But he didn't said that only "readonly read committed" transactions have this feature.

Check parameters of DBX's hidded transaction

[firebird-automations]

Commented by: @livius2

Vlad Khorsun - [16/Oct/08 08:09 AM ]
---
I have this confirmed by e.g. Craig Stuntz
look at
"Hidden transaction when connect to firebird with Borland dbExress driver like dbexpint.dll .."
at
embarcadero.public.delphi.database.dbexpress
---
a) I see no your examples there
becaouse Interbase work good in this case and i do not wrote it there

Vlad Khorsun - [16/Oct/08 07:57 AM ]

--------
look at this situation (my sample):

I.
1. start transaction A
2. then start transaction B
3. transaction A update record in table A
4. transaction B update record in table B
5. transaction B commit

and in this situation garbage collector should remove record version in table B
-------

>>No, because txA can read table B and must see old record version
i ask for what?
- only snapshot transaction need this old record version
read commited need only newest record version (or record versions created by this transaction itself)

is this true?

correct me if i'am wrong
no one snapshot transaction
1. transaction A1 (read commited) start
2. transaction A2 (read commited) start
3. transaction A1 update record no. 1 and in database now exists 2 record version of record no. 1 - orginal and not commited version created by transaction A1
4. transaction A2 update record no. 2 and in database now exists 2 record version of record no2. - orginal and not commited version created by transaction A2
5. transaction A2 commit - then first record version of record no. 2 can be deleted???
and second is now only good one

and i ask for what transaction A1 need this first record version?
if you do select in context of A1 transaction you get second record version no first yes or not?

[firebird-automations]

Commented by: @hvlad

Karol,

---
i ask for what?
- only snapshot transaction need this old record version
read commited need only newest record version (or record versions created by this transaction itself)

is this true?
---
Yes. But you didn't wrote about it before. And in general case your examples above are wrong.

We came to pure support question. Its better to discuss it in support list. General questions about transactions and garbage collection was answered many times in many places. If you can't found what you need, ask in support list.

If you have real reproducible case where IB can cleanup garbage but FB can't - post it to the tracker with as much details as you have.
But don't expect any change in FB 1.5.x series.

[firebird-automations]

Commented by: @livius2

Reading your post i suppose that all work ok in FB2 series?
and only long running transactions lock garbage collector in 1.5 series
if yes then this should be closed
and i need only upgrade my systems from 1.5 series to 2 series of Firebird.

my examples should have name "hint" - i only put some my refink where garbage collector should work
i do not see source code of garbage collector then i can not know how it work already.
And as i say if this work ok with long running transaction then this should be closed :)

i have another "hint" of this - may be this work alread i do not know
garbage collector also should not be locked also by snapshot transaction
why? snapshot transaction should only lock one record version of record another record version of the same record can be removed (or not this should be tested - some other transaction can lock another record version of the same record)

[firebird-automations]

Commented by: @hvlad

Karol, ask your support questions in support list, please.

[firebird-automations]

Modified by: @hvlad

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Cannot Reproduce [ 5 ]

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]