[MUD-Dev] World Persistence, flat files v/s DB v/s ??

Jon A. Lambert jlsysinc at ix.netcom.com
Thu Mar 26 00:06:40 CET 1998


On 24 Mar 98 at 21:42, Vadim Tkachenko wrote:
> Chris Gray wrote:
> > 
> > [Vadim Tkachenko:]
> > 
> > :- You strictly divide the persistence engine from the logic;
> > :- You build the two-tiered system with the logic as a client and the
> > :persistence engine as a server;
> > :- You build them in such a way that doesn't require them both to be
> > :within the same binary (address space, whatever), or build the adaptor
> > :which will be within and will connect to the persistence engine outside;
> > :- Your problem is fixed, because as soon as you finish that, you don't
> > :have a limitation to run those thousands of threads on the same box -
> > :you can spread them through several servers.
> > 
> > Some potential problems:
> > 
> >     - if multiple threads are updating the single image of the DB
> >         (whether those threads are local or remote), then you need some
> >         kind of consistency mechanism. If you use locks, then you are
> >         vulnerable to a client vanishing when it holds locks - you will
> >         have to detect that and rip the locks away.
> 
> Sure, that's why there is a concept of a business logic - client doesn't
> hold any locks at all. Everything is split into transactions, and any
> possible locks are handled by the business logic.
>

Yes, yes, yes.  An excellent way to look at this.  Locking strategy 
and transaction content ARE business logic.  Business logic in a mud 
roughly corresponds to real life activity.  Throwing the spear, 
opening the door, whispering, etc.   Many servers resemble a 
three-tiered system, driver/mudlib/client.


--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--



More information about the mud-dev-archive mailing list