A system I'm sure not many of you are very familiar with - MOO - has similar issues. Basically, it's another form of a MUD (multi-user dungeons/domains/etc - text-based multi-user gaming environment) which deals more with programming than gaming. In any event, the entire database file - which includes all code, 'rooms', players, etc - is loaded into memory at boot. The admin defines a certain 'checkpoint interval', say 3600 seconds (1 hour), after which a copy of the database is actually made in RAM, but locked (the primary still runs), and is written to disk (usually a file.db.new). It's not always perfect (of course). But, that's how they deal with it (granted the base system is probably around a decade old..). Depending upon system volatility and amount of data transfer and database size, you would need to alter the saving times, or even break the db into multiple files with a single prime 'index', so to speak, to keep in RAM. Err, course, these are comments from someone who's never done any actual DB coding.. *blushes* Just seem like semi-obvious solutions.
> Well, let's say that I am after simple db system like you created. But - > I do have mental conflict with "in-memory" - What do I not understand is > - when is status of db written to the disk? Apps tend to crash! If we > will not have enough granularity for 'commit-db-to-disk, it will not be > good ... > > -pekr- > > > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
