[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