At 02:01 PM 23/06/2003 +0200, you wrote:

> > You shouldn't set ALL transactions' isolation level to concurrency.
> >Only report transactions that need serializable read. Update/insert
> >transactions may be (and should be) "read commited".
> >
> > SY, Dimitry Sibiryakov.
>
>Thanks Dimitry.
>
>Why?

ReadCommitted allows the transaction to see changes that were committed by
other transactions after it started. The broad rule of thumb is that you
use concurrency for tasks that need a stable view of the data from
beginning to end; and you use readcommitted where it's important that your
transaction is aware of the latest state of the database.

I commented that, in your scenario, where every piece of action in the
current shift is operating on new records, it doesn't make any difference
whether you use concurrency or readcommitted. Your pump task (an insert)
will be finished and committed before that row gets accessed at the cash
register. It's a fairly rare thing to have such completely atomic workflows.

It won't *hurt* to use readcommitted for the pumps and the cash register,
just that it doesn't seem to make a difference here.

heLen