5 ms·
It doesn't sound like a lot if it is processed linearly. However, 10,000 reader/writers on a single shared resource is a lot. Naive implementations would have
by jpollock 14y ago
It doesn't sound like a lot if it is processed linearly. However, 10,000 reader/writers on a single shared resource is a lot.
Naive implementations would have a single global lock on the resource, resulting in lots of contention. They appear to be saying that by converting to callbacks, they are able to determine which transactions will interfere with each other and limit the contention to just those portions. Deadlock would be a serious possibility here, same as in regular databases.
The size of the data is largely unimportant for this problem, it's the contention that's the issue.
If the spaceships didn't have to interact through the global state then you could have sharding. You can change the problem by adding "planetary systems", and saying that ships in one system can't interact with another. Instant shard.
- pron 14y agoRight. That's the whole point: shards are a solution that imposes constraints on the application, meaning it's not really a solution. Also, SpaceBase guarantees no deadlocks.
- jpollock 14y agoAccording to the documentation, it does this by preventing callbacks from initiating transactions on the same SpaceBase store? :) :) :) Isn't that a constraint on the application? :) :) :) I think I'm going to have to look at the demo and see how a shot which triggers an explosion then does the query to perform the push of the surrounding ships. I would expect something like: Ship A: Query(origin+direction+range, callback Shot()) Shot() if Exploding Delete Query(origin, range, callback Boom()) Boom() Update location Except that's not allowed? An AOE which causes cascades of death would be cool to see too. Nifty idea.
- pron 14y agoI guess we must have missed all the places in the documentation where this is mentioned. As you see in the code, this limitation is no longer in place.