From: Bill Kelly <billk@...>
Date: 2010-01-15T16:49:59+09:00
Subject: Re: Recommended Reading (also:  Arrays/Hashes)

Marnen Laibow-Koser wrote:
>
> Once you have 2 users -- or 1 user doing multiple simultaneous things -- 
> you have potential concurrency issues.  SQLite is not a suitable 
> database in that case.  Fortunately, there are enough decent database 
> abstraction layers for Ruby (ActiveRecord, Sequel, DataMapper...) that 
> if you use one (and you probably should), switching DBs later on will 
> not be a huge problem.  Just be aware that you're likely to hit a wall 
> with SQLite fairly soon.

On the other hand, a MUD may not require the sort of arbitrarily
generalized support for concurrency provided by postgresql.

I have an architecture at present which, although I am currently
using postgresql, it should work similarly well with SQLite.
(It's not a MUD, but I suspect a MUD could work similarly.)

Players connect to servers in their geographical region, and
each of those game servers in turn is in communication with a
single central master server.  Ultimately there is a single ruby
process on the back-end providing database services.

So even though there are game servers on multiple continents,
ultimately there is one single-threaded ruby process running
EventMachine brokering all requests to the database.

I can get away with that because I don't need arbitrarily
granular concurrency at the database level.  The single client
of the database is the "master game server", and the set of
different kinds of queries and updates it can make to the
database service is limited and known beforehand.


(Actually I do have one separate database services process
for handling long-running non-indexed administrative queries,
so I am taking advantage of postgres' concurrency abilities
there a bit -- but such queries aren't part of the game
proper, but are made occasionally by admins.)


Oh well, just some thoughts...


Regards,

Bill