How should I handle persistence in a Java MUD? OptimisticLockException handling

I'm re-implementing a old BBS MUD game in Java with permission from the original developers. Currently I'm using Java EE 6 with EJB Session facades for the game logic and JPA for the persistence. A big reason I picked session beans is JTA.

I'm more experienced with web apps in which if you get an OptimisticLockException you just catch it and tell the user their data is stale and they need to re-apply/re-submit. Responding with "try again" all the time in a multi-user game would make for a horrible experience. Given that I'd expect several people to be targeting a single monster during a fight I think the chance of an OptimisticLockException would be high.

My view code, the part presenting a telnet CLI, is the EJB client. Should I be catching the PersistenceExceptions and TransactionRolledbackLocalExceptions and just retrying? How do you decide when to stop?

Should I switch to pessimistic locking?

Is persisting after every user command overkill? Should I be loading the entire 开发者_开发问答world in RAM and dumping the state every couple of minutes?

Do I make my session facade a EJB 3.1 singleton which would function as a choke point and therefore eliminating the need to do any type of JPA locking? EJB 3.1 singletons function as a multiple reader/single writer design (you annotate the methods as readers and writers).

Basically, what is the best design and java persistence API for highly concurrent data changes in an application where it is not acceptable to present resubmit/retry prompts to the user?

I can't help but feel that you're massively overcomplicating what should be a simple issue.

Commercial and successful MMOs often take an approach like this:

Every few minutes or after a significant action:
    copy the player data
    pass the player data to a background thread

In the background thread:
    write each piece of player data to the database

There aren't 'highly concurrent' data changes because each player saves his own data, to different rows of the database. (In some cases, this is literally one row - several commercial games just store the player data as a Blob against the user id.) Sometimes the data is a bit stale, but that's unimportant. It'll only be a problem if the server crashes because otherwise you'll eventually get the current state into the DB. This isn't inter-bank credit transfers we're talking about.

As for MUDs and BBS games, their algorithm would have been simpler still:

Every few minutes or after a significant action:
    For each property in the player object:
        write a property to the player's file

Again, there is no contention here, because each player has their own file.

Persisting after every user command is indeed overkill, unless your game is highly monetized and there's a risk of people suing you if they lose their +3 Axe of Awesome due to a server crash.

And what else in the world do you need to persist other than the players? There are often negative gameplay implications for persisting everything else, so usually you don't want to do this.

As for 'concurrent' access to the same monster, as per your example, it doesn't matter. If you have a single process, the monster should be in RAM. Your single process arbitrates who gets to hit the monster and in what order. This isn't a job for your persistence layer. Handle the game logic in the game and persist the results.

If I remember right, many of the classic MUDs did indeed load the entire world in RAM and dump the state periodically. Of course, my memories are from the day that a 16MB process size was considered terrifying.