|Subject||Re: [Firebird-Architect] Blocking garbage collection, read committed|
> Ann W. Harrison wrote:...
Excellent explain of current state of things !
> So, suppose we add another lock series, just to hold the blob limitHmm, why do you want to change behavior of current transaction lock data ?
> value for read-committed transactions. Those transactions would put a
> minus one in the lock data for their transaction lock and take out
> another lock in the new series. That lock would contain the transaction
> id of the oldest transaction currently running. When computing garbage
> collection limits, the engine queries both lock series, taking the GC
> Limit from the transaction locks and the BLOB Limit from the new series.
As i understand we agreed that "read commited write" transactions must store
its own transaction number in its lock data (instead of found during TRA_start
oldest active number) ?
> When a read-committed transaction does a commit-retaining (or rollbackThe same question as above
> retaining), it creates a new transaction lock block with a minus one for
> lock data,
> but retains the lock it has in the new series.Agreed
> Thus blob-idsOf course
> would be reliable across a commit-retaining, which makes sense to me,
> since the general description is that a commit-retaining "retains the
> context" of the transaction.
> We eliminate the current "pre-committed" status for read-only readDo you want to delete "pre-committed" status from the engine ?
> committed transactions - it causes "blob not found" errors.
> This technique makes blob retrieval reliable for all read committedI want to think the same
> transactions (fixing a bug) and keeps all read committed transactions
> from block most garbage collections. In short, it's better than what
> InterBase is doing, and it works.
> At least, I think it works.