quote: Original post by Kensai

I''ve though about this and I would do something a bit similar, but likely without the use of files. Basically, every time an important state-change occurs (like when a player gives another player an item) the transaction is stuck on a queue. It would be the job of another thread or process to just sit on the queue and process each transaction into the database. Now say a crash occurs. Chances are the queue isn''t empty. But it really doesn''t matter because if the database is designed correctly no duping occurs. When the server comes back up, some of the transactions simply never occurred.

I''m doing a lot of distributed database stuff right now and my queries blow through in milliseconds and the CPU load 9from the SQL process) is pratcically nil (since the SQL server is the thing doing all the work). There are actually a few tricks to making SQL an effective realtime system. Besides all the usual tweaking, all your operations should be stored procedures. This provides a HUGE benefit over normal queries, as stored procedures are precompiled.

The only issue I see is that if you drop the transaction, you have to be sure that the transactions dropped are not ones that would adversly effect a character. Last thing you would want to do is kill a character and then drop the transaction that builds his corpse. You''ll lose players that way. This is why I have decided to record everything to permanent media before writing to the database.

Kressilac



Derek Licciardi

VP Product Development
Check out www.greatshot.com