I’m writing a game client as a personal project and using using it as a vehicle to learn about Java database access, specifically Neo4j, and possibly Spring Data Neo4j if I decide it’s appropriate. I’m well aware that my application is a bit unconventional, and this has raised questions that are hard frame narrowly. I hope this question is appropriate for this site.
Maybe the best way to ask this is to first explain what I’m thinking of doing and why. My main reason for incorporating a database is persistence, not queryability. Because reaction times are critical, my plan is for the primary model of the game state to be an in-memory POJO graph. I want to update the persistent database in an asynchronous, eventually-consistent way. If I understand correctly, this is the reverse of most database applications, in which the database is authoritative and the in-memory data is just a snapshot copy.
Is there a name for this pattern? If you’ve written something like this, what are some of the pitfalls I may encounter? Is it naive to even try this?
3
One pitfall is that if there is a power outage you will loose values which have not yet been persisted.
The architecture you describe is similar to that which commercial in-memory databases use (SAP Hana, Microsoft “Hekaton” etc.). These address this problem by using efficient write-ahead logging. You may be able to implement a version of that if data loss is not acceptable in your use case.
1
This is a fairly standard asynchronous programming pattern – I don’t know if it has a name, but it is certainly the way that you might work with a lot of cloud solutions where you are working with NoSQL databases and most of the time you are dropping data into a queue from your application as it is updated and then expecting it will be persisted into the store when the application is ready. Most of the time data is only retrieved from the store when a new request begins or on application restart, so the in-memory model is the definitive one.
The thing that will help you out with this is knowing that you will probably want to use some kind of messaging queue to pass your data into the database- that should ensure that all your updates arrive and that they arrive in the correct order, but your front-end application can effectively drop things into the queue and forget about them. The data store then runs in its own process, picks queued items up and executes them whenever it can. This is also a really useful pattern to be aware of if you start looking at moving into distributed environments.
3
> what are some of the pitfalls ?
your app is not scalable. in other words: you cannot use a cloud/cluster to improve performance by adding more servers, if you have to many (thousands of) simultanious users.
As long as the number of users is limited so that the “in memory graph” can be handled with one server it is ok.