Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Buffering vs Begin..End Transaction
Message
 
To
25/12/1999 20:15:36
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00305569
Message ID:
00308587
Views:
19
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.)
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform