MV3D Development Blog

So, I’ve migrated all of MV3D to using a new type of datastore that has Axiom as its back end. It’s pretty sweet and really wasn’t a lot of code. The interface is the same as the other MV3D datastores, so it was pretty much a drop in replacement. It is very fast and uses transactions for extra speed. I haven’t compared, but I think it’s slightly faster than my SyncFile datastore, which is what everything in MV3D used except the Sim service. The Sim service has the unique requirement that the data it needs to save changes 20x per second. In practical use situations, it’ll also have tons of data to store. Clearly, saving 20x per second isn’t an option, so instead, it saves everything every so often. One problem with doing that is that if you have 500 objects in an area, you have to save all 500 in the same physics iteration or else your simulation is out of whack when you load it. This makes for a pretty tough challenge, and I’d venture a guess that it’s one of the big reasons why MMORPGs don’t have completely dynamic worlds like MV3D.

The solution I came up with before Axiom was a memory based datastore that could sync to disk in its own thread. What would happen is that it would store all the objects in a big python dictionary in memory synchronously. With 700 objects, this takes a little less than 1/2 a second on my system. Then, it stores that dictionary to a flat file in a thread. This means that the simulation is only interrupted for 1/2 a second. That’s still not perfect, but I figured it may work to cheat a little bit and have say 1/2 of the objects be from t, and the other from t+1. That way, it’d only be 1/4 of a second hold up.

Unfortunately, I haven’t come up with a way to do something similar with the Axiom based store. Right now, it starts a big transaction and stores all the objects using Axiom which takes about 5 seconds. Having everything stopped for 5 seconds on the server is definitely not something I can do.

The best idea I’ve come up with so far is to grab all the attributes of the objects I need to save synchronously (which should take < 0.5 seconds) and then stuff them into a cooperator that stores a few at a time through Axiom. My only fear with that approach is that it’ll take a lot more time to store everything. Actually, this could be done in a nice way. I could make a new Axiom based datastore that stores things to memory initially, but when you call it’s ’sync’ method, it iterates through all the things you’ve stored and saves them through Axiom.

Of course, there is a relatively big issue with that approach. There is no way to do everything in a single transaction, so if something went wrong while it was half way through storing in Axiom, it can’t be rolled back. I could use a trick I learned from a DBA at my job, though. Add an extra attribute that signifies that an object in the database is active, and set that attribute on all the objects if everything succeeds. I’m not sure that would save me any time, but what I can do is to add an attribute for revision number (or timestamp) which would be the same for all objects and have a separate Axiom object that specifies the most recent revision that was successfully stored.