All geek questions in one place

How should I handle persistence in Java MUD? Processing OptimisticLockException

I will reprogram the old BBS MUD game in Java with permission from the original developers. I am currently using Java EE 6 with EJB Session facades for game logic and JPA for saving. The big reason I chose the beans session is because of the JTA.

I am more experienced with web applications in which if you get an OptimisticLockException, you just catch it and tell the user that their data is out of date and they need to resubmit / resend. Responding to "try again" all the time in a multiplayer game would create a terrible experience. Given that I expect several people to be targeted at the same monster during the battle, I think the probability of an OptimisticLockException exception will be high.

My view code, part representing the telnet CLI, is an EJB client. Should I catch the values ​​of PersistenceExceptions and TransactionRolledbackLocalExceptions and just try again? How do you decide when to stop?

Should I switch to pessimistic blocking?

Is it saved after the overflow of each user command? Should I load the whole world into RAM and unload the state every couple of minutes?

Am I making my session facade an EJB 3.1 singlet that will function as a decay point and therefore eliminate the need to make any JPA locks? EJB 3.1 singletones function as a design with multiple readers / single writers (you comment on methods as readers and writers).

Basically, what is the best Java-compatible design and API for highly competitive data changes in an application where it is not acceptable to submit a re-send / retry request to a user?

+3
source share
2 answers

, , .

MMO :

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

"" , . ( - Blob .) , . , . , .

MUD BBS, :

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

, , .

, , , , , +3 Axy Awesome - .

, ? , .

"" , , . , . , . persistence. .

+4

, MUD . , , 16 .

+1

Source: https://habr.com/ru/post/1737970/

More articles:


All Articles