[noodles]

I've done it several ways, none of which were in Java however.

When working in an LPC MUD, it had flat file based persistence. You could save an object to a file, where the .o file was text based and human readable (the format was called mudmode, you can find a good enough description here ). The format is quite robust, allowing removal and addition of new fields as long as the logic in the overlying object does not change to be incompatible with existing persisted data. I'd only go with this approach in future if I really wanted to keep things simple or to use as an interim solution for the sake of prototyping.

Object relational mapping was too heavyweight and coupled for me. If I wanted to implement a feature, it required too much work doing the persistence support and the feature tended to be affected by that support.

Relational databases are my solution of choice. Straightforward database tables, with one layer of abstraction provided by the stored procedures used to access them. Another layer on top of that which wraps the stored procedures and if necessary and practical, caches and wraps access and modification of that data. Then the game logic over and above that. At first, I might prototype the service to execute SQL inline and when the data needs are concrete, solidify it into the final tables or stored procedures.

I wouldn't cache at all actually. Given a good way to profile where the database load comes from, plugging in caching where needed is a decoupled action that happens in the stored procedure calling layer between the game logic and the database that you can just do when needed.