[MUD-Dev] using DB to store game state

[Eli Stevens]

----- Original Message -----
From: "J C Lawrence" <claw at cp.net>
To: <mud-dev at kanga.nu>
Sent: Monday, June 26, 2000 7:28 PM
Subject: Re: [MUD-Dev] using DB to store game state

> On Mon, 26 Jun 2000 16:21:14 -0500
> Eli Stevens <wickedgrey at wickedgrey.com> wrote:
>
> > It features "atomic commits" (my term, I think)...
>
> Nope, old term.  You might like to also look at the definition of
> ACID as relates to databases.  From the TPC-W Frequently Asked
> Questions (FAQ) (happened to have a convenient definition):

Ahh.  Things get lodged in my head and I don't know where they come from.
:)  Can you tell I'm new at this?  :)


> > It also means that if an event crashes the mud, I can go back and
> > examine the event flagged as executing (or the next event to
> > execute, same thing) and hopefully figure out what is going wrong.
>
> Yup.  You might like to examine the previous list traffic on my
> dispatchor/executor/thread_pool model I used for Murkle as the area
> of failing events and their proper handling was well examined (tho
> "failing" was defined differently than "crashing")..

Threading was one of those things that I considered using for the project,
but I decided that I should stay away from for now because of the
difficulty/effort in making it work correctly.  I know that I will have to
tackle it sometime, but a single threaded MUD is ambitious enough for me
right now (don't get me wrong, the internal debate was long, hard fought and
swung both ways, but in the end I decided that I needed to prove to myself
that I could do it at all first :).


> > I have reservations about this scheme, because objects (I am using
> > C++) in memory will either not be persistent (they would be
> > reconstructed from the DB for every event that needed to touch the
> > object) or I would have to devise a cashing system that would mark
> > when an object should be reconstructed.  Another possibility would
> > be to eschew OO, but I don't like tha idea very much.
>
> Have a look at the approach the Texas Persistent Store takes via
> Pointer Swizzling.  I doubt that you really want to get involved in
> Pointer Swizzling with MetaKit (on quick glance it takes a different
> tack), but the approach that Texas' took for cacheing the working
> set are pretty good.

I have been searching the web for info on Texas, and everything I have found
that promises any level of detail points to ftp.cs.utexas.edu, which is not
currently accepting (my, at least) FTP connections.  What little I can find,
however, does look interesting.  I have sent an email to utexas.edu, but I
have no idea if they will be able to help.  Does anyone know of/have local
copies of information on the Texas Persistent Store?

<//> Silence is golden           RUIN, v.  To destroy.            <\\>
 ||  Eli                         Specifically, to destroy a maid's ||
 ||  wickedgrey at wickedgrey.com   belief in the virtue of maids.    ||
<\\> www.wickedgrey.com            -- Ambrose Bierce              <//>







_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev