This idea is based on Secondlife. But I think a reliable grid could be used for more than massive multi player games. Several terms come from Secondlife, but there are some differences in my concept, when it comes to region, yield and commit.
All seminal works in distributed systems, but as far as I can tell, there's little overlap with what OP is proposing.
It's a pretty cool architecture, but the major drawback is that you're making events quite expensive with ACID guarantees.
The more expensive events are, the less you can rely on them as a communication primitive. What if I want to submit a logging or tracing event? I don't really need ACID guarantees in that context, and it's a heavy burden on the system.
It might be nice if events had optional tags that defined what sort of policies to enact on them. One could say, "I don't need ACID guarantees on me."
The overlap point for me (and I'm too quick because these papers and tools have been knocking around in my head lately) is once you mention what happens in a fatal server crash and you've listed durability as a requirement, we've stepped into the topics those sources cover.
I like the idea of tagged events - flagging events so that your event queue package could handle the heavy lifting on how strongly to enforce ACID guarantees by event seems like the kind of feature that would make for happy hacking in distributed systems.
Secondlife does not warranty any transaction. My idea is, that server admin can deceide, if a server does ACID only, is allowed to relax to eventual consistency, or even allowed to drop replications under load. While the script author can decide that there are events that must be ACID, even under heavy load.
