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

[Vadim Tkachenko]

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.

When the client dies, there are two possibilities - one, it drops the
connection, which automatically leads to the IOException and depending
on the higher-level protocol handling it's either disconnected or put
into the linkdead state. Two, it lags out, which is worse but can be
handled somehow - any comments on this case?

>         This also means
>         that your execution model has to be very complete with respect
>         to locks,

Always :-)

>         both read locks and write locks.

The single-write, multiple-read access is the usual way of handling
that. Then come the different insulation levels...

>         With remotely held
>         locks, you can get some *very* large latencies.

Never have the remotely held locks, then :-)

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

What is that? Can you give me a reference, please?

>         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?

I'd probably have a special kind of 'broadcast handler' business logic
(BL) to do that (as I mentioned before, the BL adaptors are stackable,
and there may be three ways of handling the request by the BL adaptor:

- The response is delivered by using 'return anObject' from within a BL
adaptor, which passes it down the BL chain;
- The response is thrown within the exception (I use the special kind of
exception which can hold the java.lang.Object inside), and then is being
immediately delivered as the final answer;
- If the response comes unmodified beyond the last BL in the chain, the
UnsupportedRequestException is delivered to the client.

So, going back in stack, the broadcast handler will be probably one of
the first in chain and will not increase the load on other parts of 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.

Can't answer this yet, the first thought is that I try to follow the MVC
paradigm, and everything on the other end of the connection is either V
or C for me, so all the data you're talking about here will probably end
up in the BLs on the server side.

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

--
Still alive and smile stays on,
Vadim Tkachenko <vt at freehold.crocodile.org>
--
UNIX _is_ user friendly, he's just very picky about who his friends are