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

[Chris Gray]

[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. This also means
	that your execution model has to be very complete with respect
	to locks, both read locks and write locks. With remotely held
	locks, you can get some *very* large latencies.

	Alternatively, you might try Chris L's lockless scheme, or some
	variant.

	In either case, information generated by a thread run often
	produces output that must go to several clients. Does each
	client know about all other clients, and so can send directly,
	or does that information have to bounce through the server?

    - threads often need a fair amount of context (mostly read-only) to run.
	Getting the up-to-date version of that to the clients can up your
	latency quite a bit. You can cache information like that on the
	clients, but see recent discussion on that for some hazards.

	If you use Chris L's lockless scheme, then after the thread has
	run, you need to send full images of changed stuff back to the
	server so that it can be compared and committed. Again, lots of
	traffic and latency. Also, that C & C may take nearly as long as
	the thread execution, so you end up losing out, in terms of the
	latency seen by the user.

A fully multithreaded server, using Chris L's C&C method, running on a
large multi-CPU SMP machine is likely the best way to get high throughput.

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA