[MUD-Dev] On Lockless Threading and X/Open XA

[KevinL]

gunderwood at donet.com wrote:
> Bruce <bruce at puremagic.com> writes:
> 
> > Apart from abandoning C&C-style plans, does anyone see a way to marry
> > these two types of systems, or even some other solution for lockless
> > threading that might mesh better with a 2 phase commit-based system? 
> > Are there other systems out there for handling distributed transactions?
> 
> My initial thought would be to have the 2PC be the commit part of the C&C. 
> Any reason something that simple wouldn't work?
> 
> It's been a while since I did an in-depth read on either protocol, but I
> don't think 2PC is necessarily anathma to a C&C approach.  IIRC, what it
> buys you is the ability to rollback failed, partial commits.
> 
> Mind if I ask a design question?  Why such a complicated back end?  All the
> MUDs I've played on have had much simpler systems, and seemed to run just
> fine.  Was I missing out?  :)

Once you start solving some of the potential problems in back-end, it's hard 
to stop ;)

(My own opinion follows, feel free to treat it with as much sympathy as it's 
paid for ;)

Seriously, there's a batch of problems out there for mud's with separated data 
stores that _might_ bite, and there's a bunch of situations that _might_ 
confuse the player - weird little locking issues.  If you want to be thorough, 
fixing them becomes fairly expensive in terms of the complexity of the 
algorithm.

It's like locking - I've seen threaded programs that run without any locking, 
and run fine under light load or under certain usage patterns.  Put them under 
the right conditions, however, and they'll fail.  Whether the failure is 
catastrophic or just a nuisance remains to be seen ;)  If you want to wing it, 
you put checking to make sure any failures are not catastrophic, and you live 
with it.  If you want to "solve" the root cause of the problem, then things 
get really funky...

For example, most players will live with a situation where the attack command 
goes through, the object they're attacking moves away, and the attack command 
breaks, _if_ it breaks cleanly - they'll assume lag or similar.  But if you 
want to actually solve this, stop these things from happening, you need ways 
to guarantee that something that's in the process of entering combat won't 
just wander off/be teleported/whatever, without locking up the object too 
badly or risking deadlock, etc. etc. and so it goes...

For someone building a backend for potentially lots of other muds, of course, 
the problem is real and must be fixed ;)  For someone working on their own 
mud, you might decide it's just the way things are and fixing it is far too 
much trouble to be worthwhile.

KevinL
(still trying to find the universal solution, damnit ;)




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