¿Cómo debo manejar la persistencia en un MUD Java? manejo OptimisticLockException

Question

Estoy re-implementación de un juego MUD BBS de edad en Java con el permiso de los desarrolladores originales. Actualmente estoy usando Java EE 6 con fachadas EJB de sesión para la lógica del juego y JPA para la persistencia. Una gran razón escogí beans de sesión es JTA.

tengo más experiencia con las aplicaciones web en la que si obtiene un OptimisticLockException que acaba de coger y le dice al usuario que sus datos son obsoletos y necesitan volver a solicitar / re-enviar. Respondiendo con "intentarlo de nuevo" todo el tiempo en un juego multi-usuario haría para una experiencia horrible. Teniendo en cuenta que yo esperaría que varias personas sean dirigidas a un único monstruo durante una pelea creo que la posibilidad de un OptimisticLockException sería alto.

Mi código de la vista, la parte que se presenta una CLI telnet, es el cliente EJB. ¿Debo agarrar la PersistenceExceptions y TransactionRolledbackLocalExceptions y acaba de volver a intentar? ¿Cómo decidir cuándo parar?

¿Debo cambiar a bloqueo pesimista?

persiste después de cada comando de usuario exageración? ¿Debo estar cargando el mundo entero en la memoria RAM y el vertido del estado cada par de minutos?

¿Hago mi sesión fachada de un EJB 3.1 Singleton que funcionaría como un cuello de botella y por lo tanto elimina la necesidad de hacer ningún tipo de bloqueo APP? EJB 3.1 únicos funcionan como un diseño de múltiples lector / escritor simple (que anotar los métodos como lectores y escritores).

Básicamente, ¿cuál es el mejor diseño y Java Persistence API para cambios de datos altamente concurrentes en una aplicación en la que no es aceptable para presentar volver a ejecutar / reintento le pide al usuario?

Answer 1

No puedo evitar sentir que estás masivamente complicar lo que debería ser un tema sencillo.

MMO comerciales y exitosos a menudo toman un enfoque como este:

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

No hay '' altamente concurrentes cambios de datos, ya que cada jugador guarda sus propios datos, a diferentes filas de la base de datos. (En algunos casos, esto es literalmente una fila - varios juegos comerciales simplemente almacenar los datos de los jugadores como una gota en contra de la identificación del usuario.) A veces los datos son un poco rancio, pero eso es poco importante. Sólo será un problema si el servidor se bloquea porque de otra manera que finalmente va a obtener el estado actual en la base de datos. No se trata de transferencias de crédito entre bancos que estamos hablando.

En cuanto a la MUD y juegos de BBS, su algoritmo habría sido más sencillo todavía:

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

Una vez más, no hay contienda, ya que cada jugador tiene su propio archivo.

persistir después de cada comando de usuario es de hecho una exageración, a menos que su juego es muy monetizado y hay un riesgo de que la gente está demandando si pierden su Ax 3 de impresionante debido a una avería en el servidor.

Y qué otro lugar del mundo se necesita para persistir aparte de los jugadores? A menudo hay consecuencias negativas para la persistencia de juego todo lo demás, por lo que normalmente no desea hacerlo.

En cuanto al acceso 'concurrente' al mismo monstruo, como por su ejemplo, no importa. Si usted tiene un solo proceso, el monstruo debe estar en la memoria RAM. Su único proceso arbitra que llega a golpear al monstruo y en qué orden. Este no es un trabajo para su capa de persistencia. Manejar la lógica del juego en el juego y persisten los resultados.

Answer 2

Si no recuerdo mal, muchos de los lodos clásicos, efectivamente, cargue el mundo entero en la memoria RAM y volcar el estado periódicamente. Por supuesto, mis recuerdos son desde el día en que un tamaño de 16 MB proceso se consideró aterradora.