Though a lurker here, I am using and have great hopes for IB. I would
agree both on the general guidleines for adding competing features, as
well as on the "dirtier" isolation levels. On many systems they result
is significnatly reduced overhead when using a read-only data source.
Whilethe performance gains may or may not apply in IB, people are used
to it, and well, perception is reality.

That said, I also have another question for the Architect group. I have
been evaluating the superserver versus classic model and classic seems
to offer me some significant advantages (I'm running Superserver right
now on an SMP Linux box). Before migrating to it however, I was
wondering what the long term goals are. Is the classic model going to
continue to be supported?

Thanks!

Dmitry Kuzmenko wrote:

> Hello, Ann!
>
> "Ann W. Harrison" wrote:
>
>>> - because I can imagine _useful_ using of such "feature"
>>> i.e. finding out who has updated and not committed specific record,
>>> which is operation that requires by its nature looking at uncommitted
>>> data or some internal structures.
>>
>> I guess I don't understand why read-uncommitted would give you any
>> information about a locked up record. When you read a committed
>> record, you don't know who committed it. Why should uncommitted
>> records be different.
>
>
> Ann, please, don't resist. <g> If there is a feature that can be implemented like piece of cake,
> and this feature is a part of competing SQL-servers, this feature
> MUST be implemented. Interbase will have extended functionality that can add points
> in competition.
>
> I too hate "dirty read" isolation level, but it is standard isolation mode. As you know,
> IB now have only one (1) isolation mode that is equal to ANSI - it's READ COMMITTED.
> If it can be implemented writing 20-30 lines of code - why not?
>