burmair wrote:

>>>> ...In terms of performance, is it faster to do as much as
>>>>> possible in a single transaction (or maybe a few "chunks"),
>>>>> or is it essentially the same if each update is performed in
>>>>> its own transaction?...

All of the people who have told you that you should look for
logically connected pieces of work and include them all in a
single transaction are right. To use your rifle shot analogy,
if you care about the balance of energy and mass in your world,
then one transaction should enclose both the firing and the
arrival of shot at the target (or where ever it arrives). If
not, then include only those changes that are required to make
a logical whole. Transactions should transform the database
from one logically consistent state to another.

However, you persist in asking about the cost of transactions,
so here's a bit about that. First, the cost depends on whether
you're using classic or superserver. Classic is significantly
more expensive. The cost of a transaction is a write to the
database header page at transaction start and a write to the
transaction inventory page (TIP) at transaction end. The TIP
must be written to disk before the transaction is complete.

In Classic, that can mean that one process must write the header
page or TIP so the one starting or ending a transaction can read
it from disk. With several clients performing short transactions
the TIP and header page represent a significant amount of the
total system I/O.

In SuperServer, both the header and TIP are kept in the system
cache and writes can be bundled.

What this means, essentially, is that if you do single update
transactions, you're writing three pages for every change.

If you look through the list archives, you'll see lots of
warnings against long running transactions - and those are
valid. However the definition of a long-running transaction
in those cases is a single transaction that outlives tens of
thousands of its contemporaries. From your description, I
doubt that your imagining transactions that stay open for
hours or days.

You may imagine that all the changes made by a transaction are
kept in memory or a log or some other temporary location then
applied on commit. That's the way some databases work, but not
Falcon. When your transaction makes a change, the change is
written to a data page (and index pages if necessary) and the
page is kept in the process cache. It will be written to the
database if space is needed in the cache, or (in Classic) if
another process needs to change the page, or in all cases before
the transaction commits. There is no imaginary bucket that
holds uncommitted change that can overflow and drown the whole
system.

So, don't write transactions that take hours to complete, but
don't put each change in its own transaction either. In fact,
look at the logic of your application, and build transactions
that transform the database from one logically consistent state
to another.

Good luck,

Ann