[MUD-Dev] World Persistence, flat files v/s DB v/s ??
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Mar 22 10:32:32 CET 1998
[Ben Greear:]
:The two things I'm pondering now are binary flat files (one per object,
:a collection of objects?? I dunno) or a database.
A binary form has the distinct advantage that it is relatively easy to
replace a single entity in the file. With text files, variations in
formatting of things like numbers make that harder. If you need to save
more than one kind of thing in your file (fairly likely!), then you can:
- have multiple files, one per type of entity
[can be expensive in terms of file handles and space]
- reserve portions of the file for arrays of the different entities
[what happens if you overflow a portion, needing more space?]
- set up means by which varying lengths and types of things can be
interspersed in the file, and properly found and updated.
[can get complicated]
The third choice is pretty close to writing your own DB system.
:I'm a little concerned about the performance hit on a DB, as I expect
:this game server to bring a machine to it's knees anyway...
A good non-write-through cache attached to a DB layer seems to work
pretty well. Disk I/O is not really a problem on my setup, other than
when the cache gets flushed. The fix for that is to use a separate
thread to do that, so that main server processing is not delayed. You
have to be careful to write a consistent image to the disk, however,
which may require some copying of entities if the server needs to update
them while they are already marked for flushing by the separate thread.
:Also, as a java server, I don't think I can do a select on incomming
:data. I think a thread for every player is a bit much...any suggestions
:here?
I have just started into the socket programming stuff of the current Java
book I'm reading, but I just went and did some scanning. The technique
he suggests for a server is to create some fixed number of threads, and
re-use those threads throughout the lifetime of the server. He says that
some Java implementations do not garbage collect threads at all, so having
one per connection can result in an eventual crash due to lack of memory.
Ick. Given the lack of a 'select' or 'poll' method in Java, the choices
are quite limited. Double ick.
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the mud-dev-archive
mailing list