Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Buffering vs Begin..End Transaction
Message
 
À
25/12/1999 20:15:36
Cetin Basoz
Engineerica Inc.
Izmir, Turquie
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00305569
Message ID:
00308587
Vues:
20
Hi Jim,
>Seems I started a new discussion. Your point is good. This is not a reply but rather my addition.
>Sometimes I have other situations where I really want to lock all recs in a session. ie: I have an employee tracking and want to revise their records as a supervisor (or boss). I do not want anyone to tamper while I'm doing it on per topmost parent basis (I want topmost parent+allchilds locked). Pessimistic buffering would be the one I would choose. But instead I could prefer a transaction and maybe just use it as a safety belt. Needs arise sometime. As always there are many ways to skin a cat in FP. So IMHO while transactions and buffering are in close relation none is dependant to other.


Cetin,

You came into this late in the game. Your issue was discussed days ago. Buffering and transactions have nothing in common outside fo the fact that they are involved wiuth updating data. They do totally independent things and are both useful in their respective areas.

In your example I would use optimistic buffering (as that is what I always use, Optimistic tabel buffering). I would handle the administrative issue by either using a semaphore locking scheme or by programmatically obtaining all necessary locks before allowing the administrative action to begin. Transactions are reserved for combining multiple table updates (including deletes and inserts as well) into a single all or none operation. I don not use them to control locking although is could be done.

The difference would be that using my approach above I would secure all locks before I would allow the user to do antyhing. Then when the user was finished I woudl still use a transaction to wrap teh updates. Using a transaction each lock is obtained as teh table is updated. This means that the user can do some of the work and then get told the task cannot be completed.

Why also use a transaction? Becasue there are things that can happen that could allow the lock to obtained but then disallow the tableupdate from executing (like network cable broke, administrator shut down the server, etc.)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform