Subject Re: generate report for POS
Author Adam
--- In, bill_lam <bill_lam@...> wrote:
> If dirty-read is impossible, and read-uncommited is not supported,
then how to
> generate reports for busy system (eg. POS) that continuously having
> active?

MGA makes this possible. Readers don't block writers and writers don't
block readers. For this application, you would probably want to run
your report query from a read only snapshot transaction. Your report
will then see the database just as if it had its own personal copy.

If you are generating complex reports during high volume activity,
then using classic server (CS) may be a better option than Superserver
(SS), as SS can slow down a bit and CS better scales when you have
multiple processors. SS means that all connections must fight to have
their work done in a particular quantum, where with CS each connection
gets their own quantum.

Other options in extremely complex reports would be to take a (hot)
backup of the database and restore it to another machine to run
reports on.

What use is a report based on dirty reads? I have only seen one thing
that dirty reads makes easier, and it is not reporting but rather
seeing who is currently changing a record. This can of course be done
using MGA using a separate transaction to write the user that does
commit. Reports based on dirty reads are conceptually flawed, because
it is not stable or repeatable and in simple terms, you have no
confidence in getting the right numbers.