I need persistent objects for a game server and hibernate seems to be the logical choice. The data is about account data, player data, inventory, states and lots of other things.
Most examples are web server applications and I think there it should be easier to identify logical transaction boundaries.
First of all: The game server will update objects very frequently and I would like to persist only in larger intervals. Hibernates caching should help without having to care much about it in the server code.
Object state changes are mostly triggered by network messages and due to an event handler design the triggers may come from a bunch of different threads.
A unit of work in the game server is very small: load an object and detach, update an object. There are no really big transactions so I wonder how to set the boundaries so I benefit from Hibernate's features.
My first tests work well but the more I add the more I doubt my current approach. I run into problems with all these small transactions like duplicated tuples when an update should have been done, lazy loading fails because it's somewhere deep in the code and even in other threads.
Maybe I should consider the game server life cycle as one unit of work and just use one session? Would that even work?
Thanks for all comments
|