> I don't want, that Pause(true) commits a transaction, when
> a dataset is in edit-modus. So it is good as it is, I just
> asked, because it doesn't behave as in the OH described.

OK.

> I'm just thinking over, if I should use the Pause-method.
> For example 30 user work with the app and every app has
> 10 transaction open.
> 1) I use the TimeoutProps and every 60 sec for example
> will the transactions be commited. So there is no problem
> concerning the OAT, but nevertheless there are 300
> transactions at the same time open. I don't know, is this
> a lot or not ?

Like many things, the answer is; It depends :-) More below.

> 2) I use the Pause-method, so that there are max 2
> transactions running per app, but I have to manage the
> pause and resume for myself, that could be a lot of work.
>
> What do you think ?

I use the Pause functionality - on the other hand, I have not bothered
to disable the TimeoutProps that Jason has since introduced. This
means that both are operating at the same time, and it has not caused
me any trouble - indeed I think it improves the situation.

I let Jasons automation handle the fine details of trying to minimise
transaction times dynamically. I implement the Pause automation with
fairly long timeouts, simply to protect against problems with very
large datasets being left open and to protect against users leaving
edits etc open when they go home (or to lunch).


NOTE:

In most cases there is very little need to get too concerned about OAT
problems - it is simply a matter of preventing the transaction times
getting too extreme. There are two main situations we are trying to
avoid by reducing transaction times...

1. Conflicting *updates* between users.

2. Preventing backup/garbage collection.

Presuming you only do backups at night, item 2 can get by with quite
large timeouts. Item 1 is highly implementation dependant...

If you have lots of users reading data and only a few doing updates,
then there is not much chance of update conflict so timeouts can be
left quite long.

If you have lots of users doing updates, the likelyhood of conflict
increases, but still depends on how likely it is that the users will
be updating the same data - and this last aspect becomes a design
issue.

If there are many users, and they are likely to try and update the
same records then it is upto you to design the application
accordingly. Keep the forms fairly simple so that individual updates
will not take too long (and so you can keep the timeouts fairly
short). Make sure your triggers and related automation do not cascade
data changes to other tables (keep such automation for special batch
processing).

In more complex situations you may consider presenting your forms in a
"wizard" mode, where the transaction is automatically committed as
each panel of the wizard progresses (if this is appropriate).

In some instances you can reduce the potential conflict by having the
application split the data according to useage.

For example; One of my applications is used by 40 or more users at a
time. However these users are located in about 6 different branches,
so the application is designed to present (by default) only data
relevant to the particular branch. This means that there are only
about 7 or 8 users looking at the same data and so the chances of
conflict is reduced, allowing me to keep the transactions timeouts
quite long.

In very extreme circumstances (and as a last resort IMO - although
many disagree) you can revert to cached updates which will keep
transaction times as short as possible.

Remember that I am talking about UPDATES in the above. Certainly
transactions open for reading will prevent garbage collection, but the
timeout requirements for this should be quite long in most
circumstances.


To try and phrase this more succinctly; Developers need to be aware
of OAT related problems and be ready to take appropriate action. But
there is usually no need to go to extremes. Use the Status form (or
your own monitoring) to watch out for problems and fix them if they
arise.


HTH

Geoff Worboys
Telesis Computing