At 07:48 PM 12/7/2000 +0100, Toni Martir wrote:

>What does it mean run as "pre-committed", how can I start a transaction that
>don't affect the OAT in Interbase 6?

I think the mechanism was not turned on for user transactions,
but the garbage collect thread runs in that mode to avoid tying
up the OAT. An ordinary snapshot reader must be recorded as
active to preserve its view of the database. A read-committed
transaction doesn't care about consistency - whatever is committed
at the instant is OK - read the same record four times, see
four version - hey, cool. So there's no reason to hold old
versions around for read committed transactions.

The implementation, if I remember, is to set the transaction state
to committed on the TIP at start-up time. Works fine for readers,
but it would not do at all for writers.

> >Read-write read-committed transactions could be
> > made not to affect the Oldest Active Transaction, but would require a
> > different mechanism.

Read-write read-committed transactions don't care about consistency
either, so they don't need to tie down the OAT. On the other hand,
they can't be pre-committed because they might fail and need to have
their changes undone. And transactions that actually care about seeing
good data should not think that the stuff written by an active
read-committed transaction is reliable.

An alternative is to keep a bitmap of the id's of those read-write
read-committed transaction ids so they never get set as OAT. The
question is where to keep it. In the super server, that's easy -
in memory is fine. In classic, the processes communicate through
the disk (slow) and through the lock table (fast but constrained).

There are probably other options.

>Read-write transactions should be always short in time because modified
>records are locked for write by other transactions.

Right, but they aren't always that way.

> > Serializing write transactions is not an option. Table locking is bad
> > enough - locking the entire database is serious overkill.
>
>I understand the way to do it now is table reservation. It has the aditional
>work of reserving/unreserving new touched tables when the programmer
>modifies the client application.

Unreserving?

>Are this transaction always serializable?
>- Snapshot, read
>- Snapshot, write, table reservation of tables to write.
>Or I must use also table stability for write transactions?

Snapshot for read only is fine. Read-write transactions must
use table level locking for both reading and writing. In fact,
using snapshots for reading and table level locking for writing
can produce the same errors as using snapshots for everything.

And yes, table locking is serializable and should be so under
any definition. Note that the definitions of transaction isolation
modes are often very badly written and reflect their authors'
assumption that locking is the only possible mechanism.

Let me also say that "consistent read" mode that InterBase offers
has much more consistency than a system that locks records but not
access paths. The possible errors are well-understood, at least
by me, and can be programmed around easily.


Regards,

Ann
www.ibphoenix.com
We have answers.