[Home] [Groups] - Message: [Prev in Group] [Next in Group]
6771: [MUD-Dev] Re: Fw: lurker emerges
[Full Header] [Plain Text]
From: "T. Alexander Popiel" <popiel@snugharbor.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Sun, 09 Aug 1998 08:53:21 -0600
References: [1]
Organization: Kanga.Nu
In message: <005201bdc3a8$8420b520$961e5d18@default.rochester.rr.com>
"James Wilson" <jwilson@rochester.rr.com> writes:
>
>Finally, there could be a provision for multiple simultaneous commits,
>which would correctly invalidate the caches of T1 and T3 and ensure the
>large-scale correctness of the data structure.
This sort of compound action is known as a 'transaction' in DB land,
and either the entire transaction succeeds or the entire transaction
fails, atomically.
>If the large-scale structure is large, however, it would be quite possible
>that an event which needed to access every component and commit them all
>en masse could be constantly aborted by commits to the components from
>other threads.
>How could you be sure you would eventually get to commit your changes?
What you do is you request exclusive lock on all components involved in
the transaction, before beginning the transaction. At some future point,
you will be granted lock on those components (possibly after aborting or
completing other transactions which requested a similar set of components),
and you can complete your transaction in peace.
For efficiency reasons, the above-mentioned lock is usually only requested
when either you know that the components are going to be in high demand,
or your transaction has already been aborted once or twice.
- Alex