Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server
Date: 1997/12/12
Message-ID: <66re3g$qib_at_rocky.carmenta.se>#1/1
In article <3490B6CD.202C_at_agd.nsw.gov.au>, no_sp.am_at_agd.nsw.gov.au says...
>
>Johan Andersson wrote:
>
>> [.. description of testapp ..]
>
> [.. some nitpicking ..]
>
Yes, you are probably right :-)
>> NOTE!
>> It is not acceptable to use one transaction per tuple received, all or none
>> must be registred.
>
> Now this is a sticking point! Why? Assuming we are monitoring
> traffic flow, information wold be coming in from more than one source
> and it would be in real time. I suspect that it should really be
> atomic. I.e.
>
> update this vehicle
> delete this vehicle
> insert this vehicle
>
Well, it was essential for achieving larger and larger transactions which was
what my example wanted to test. Maybe we could dream up a better example or
are you saying that no such example could exist?
If we still argue from the point of view of an air traffic monitoring system though, we could assume that when a feeder sends a collection of tuples it tells the system its current view of 'its part of the sky'. If some of the tuples but not all where allowed to enter the system as you suggest, a reader might get the impression that two airplanes were in the same location, a dead sure cause of acute panic...
>> It is important to keep the average number of rows fetched by reader
>> constant.
>
> Why? I think it should be all rows that match the selection criteria.
> This will vary constantly and can't and shouldn't be controlled.
>
The idea was to adjust the test dataset so that the number of fetched rows
were constant, so as to not get response time distorted by different fetch
times. It is of minor importance though and if ignored we can simply use
random test data.
>> It is assumed that the feeders are sending new transactions repeatedly with
a
>> constant delay, small relative to transaction time, in between.
>
> The delay shouldn't be constant either. It should appear to be
>realtime.
>
Not really, if we assume that each feeder collects a set of tuples consisting
of its 'current view'. Then there should be a delay between each transmission
of such a set.
>
> You shouldn't get deadlocks with just the one table. From the design,
> it appears that only one index is required. More than likely you
> would just get blocking so it would appear to an end user as stop/
> start performance.
>
I saw a risk with two feeders updating two disjunct set of vehicles in their
respective transaction, and running into a deadlock because two pairs of
vehicles in their respective sets where on two corresponding pages, ie
V1-P1,V2-P1,V3-P2,V4-P2
feeder1 updates V1,V3 and feeder2 updates V4,V2.
- f1 locks V1 (and in a PLL system V2)
- f2 locks V4 (and in a PLL system V3)
- f1 tries to lock V3, and blocks in wait
- f2 tries to lock V2, and a deadlock occurs
- The RDBMS resolves the deadlock and f1 or f2 gets rolled back.
/Johan
-- ________________________________________________________________________ | >>> The opinions herein are mine and not neccessarily my employers <<< | | Johan Andersson, Msc CSE jna_at_carmenta.se | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Received on Fri Dec 12 1997 - 00:00:00 CET