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?

  • You wrote you need the database for persistence, but from your comment below it seems the database could be always recreated or newly created when logging into the game (which means also whenever the client process is restarted). So I am puzzled why you need a database at all - why is the in-memory model not sufficient?
    – Doc Brown
    Commented Aug 11, 2014 at 5:27
  • The database would contain history and data that is not always immediately available in the game. To clarify the comment you're referring to, losing the last few seconds of data in a power outage would not be a big deal because it's no more significant than being logged out of the game for a while, which is normal and would happen during a power outage anyway. In other words, not worrying about such losses is exactly equivalent to writing some elaborate system to prevent them and then having the power go out two seconds earlier. Commented Aug 11, 2014 at 6:35
  • 1
    The technical name for this is a write-back cache. It's not the most common caching strategy but it's fairly standard.
    – Alex
    Commented Aug 11, 2014 at 15:46

3 Answers 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.

  • Good point. But in my case, that kind of data loss is not a concern because the client needs to update its database upon logging into the game anyway. Commented Aug 11, 2014 at 4:01

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.

  • Thanks for your answer. An update queue would suit my application well. I could also run queries in the same queue as the updates, thereby guaranteeing that the results of the query reflect the updates associated with the event that triggered the query. The minor delay introduced by queueing my queries won't matter, because I won't be using the database when performance is critical. I just have to learn how much queueing is already done by the database itself and how I might take advantage of it before I roll my own external queue. Commented Aug 11, 2014 at 6:50
  • I'm still struggling with one aspect of this, though. If I use something like Spring Data Neo4j, it would seem natural for the in-memory POJO graph to consist of Spring entity classes. Whenever one of them is updated, I would queue a task to persist it. But then I don't know how to deal with the memory model visibility issues. Clone my entities and update the database from the clone snapshots? Commented Aug 12, 2014 at 4:31
  • Now Spring isn't my speciality - I've worked with this type of pattern in other languages and various other frameworks - but you might want to look at the JMS Spring integration. onjava.com/pub/a/onjava/2006/02/22/…
    – glenatron
    Commented Aug 12, 2014 at 9:18
 >  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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.