[MUD-Dev] Re: Lockless DB design (was Fw: lurker emerges)

[J C Lawrence]

On Sun, 9 Aug 1998 11:15:14 -0400 
James Wilson<jwilson at rochester.rr.com> wrote:

> 1. if one obtains an object which contains a reference to another,
> and then obtains the referent, does this require two DB hits? If
> so, perhaps a prefetching strategy could be used: requesting
> object foo gets you foo together with everything it points to (but
> nothing beyond that). This could be a loss if the larger set
> incurs extra collisions with other threads to the extent that any
> gains from prefetching are swamped.

There are two problems here that appear to be being hidden:

  1) Physical IO is slow and needs to be minimised.

  2) DB accesses from the DB cache need to be fast.

Prefetching as you describe stuffs the cache with records such that
later accesses may be faster (taking advantage of the performance
gain of #2 over #1).  However, unless accessing all those records at 
once is faster than accessing them each individually, you are not
going to gain anything and are in fact likely to lose due to the
fact that some (large?) percentage of those objects won't be
accessed and you will have spent expensive physical IO time loading
them when they are unneeded.  

Its a trade-off.  Depending on your DB structure and call tree
overhead it may be a lot faster to do something like:

  load_records (#,#,#,#,#,#);

than:

  load_record (#);
  load_record (#);
  load_record (#);
  load_record (#);
  load_record (#);
  load_record (#);

and the fact that some percentage of those loads are in fact useless
is saved by the general performance gain of the first over the
second.  Measure.  Choose.

> 2. how can one use this system to guarantee correctness when
> dealing with compound objects? 

I believe this was already answered by other posts.  No?  Briefly
this is a question of "nested transactions" to put it into DB
parlance.  You can't have child transactions compete for C&C without
critically endangering logical correctness.  You have to have child
transactions be subsumed by their parents.

> This would be a race condition (or a "dragon's door", as it has
> been termed here). 

"Dragon's Dinner" actually.  <shrug>   Many of the list members don't
have CS backgrounds, so it provides a very simple and easily
understood example of the basic problem.  (Thanks DEMOS!)

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...