I supose the objectives of the project should really control the
criteria for adding features - my opinions may not be well aligned with
that :)

Let me preface this by stating that I don't know the architecture of IB
well enough yet to know if the lower isolation levels actually impact
performance significantly or not, but it does on most databases. As far
as a reason to use it, I don't think you fully understood my point. If
you have a very large system where ninty plus percent of the
transactions are read-only, and only one process performs updates (such
as a datamart/warehouse) the reduced cost is quite worthwhile, and not
underhanded. It's a case of the system deployment being done with an
assumption that the database can't always make. That doesn't make it
invalid. How much transaction control do you need on 10,000 SELECT
statements to keep them from causing problems with each other? There is
a point where a transaction simply doens't get any less expensive, and
as volume goes up, every little bit counts.

It appears to me you would rule this out, not because you can't find a
reason for someone to want to use it, but rather because you don't think
it is a good way to run a system regardles of what other people want to
do. I'm not trying to get flamed here, but this isn't being dumb. This
is a legitimate use of the feature proposed.

Jim Starkey wrote:

> At 06:21 AM 12/27/00 -0500, Andy Lewis wrote:
>
>> 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.
>>
>
> I disagree. Before something is included, somebody should make a
> case for it. I think the minimim standard should be theoretically
> sound and useful. My feeling is that this feature fails both tests.
>
> Don't sniff glue 'cause all the other guys do it. Dumb is dumb.
> If they need an underhanded mechanism because their transaction
> control is too expensive to use, well, that's their problem, not
> ours.
>
>
> Jim Starkey
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>