burmair wrote:

>
> ... We're using the embedded server,
> which I understand is the SuperServer engine. In our case, a single
> step from one consistent state to another may involve many millions of
> discreet updates. Our problem is precisely that a single transaction
> may take a large amount of time (hours is conceivable) to complete,
>

At that point, you run into the other problem with long updates - the
increased chance of deadlocks. Since you say your using the embedded
engine, that may not be an issue for you.

>
>
> and the question becomes, at what point do the risks outweigh the
> benefits of atomicity (which is important but not critical to us,
> since the "correct" state can always be regenerated very easily if
> needed). What we've decided to do for now is just what you suggested,
> more or less. Using the spreadsheet analogy, we're treating each
> "column" as a transaction of several thousand updates, instead of a
> transaction per cell, which is what we started with. I'll let you
> know how it turns out.
>

Thatn sounds like a reasonable plan.

Cheers,

Ann