La idea es la siguiente, un MMORPG. Supongamos cientos (¿miles?) de jugadores a la vez, realizando operaciones como mover un personaje.
Entonces en RAM debo tener todo lo que los jugadores en ese momento necesiten, porque imaginaros estar todo el rato leyendo y escribiendo en el disco para operaciones que se suponen rápidas. Mi idea era ir haciendo flush cada X minutos, al igual que hacen otros mmorpg que si se caen inesperadamente al volver la gente pierde sus ultimos minutos (in incluso horas) de juego. Por lo que veo el mayor problema que tengo es que Nhibernate es incapaz de detectar cuando un objeto deja de estar apuntado (es decir, que no lo estoy usando), por lo que quedaria en memoria. Algo que pensaba que gestionaría de alguna forma y veo que no... On 13 feb, 20:17, Angel Java Lopez <[email protected]> wrote: > Hmmm... se me escapa por que tiene que estar todo en RAM, tendras un caso > de uso?... > > leer más » > > Es similar a decir: > > "es una aplicacion multiusuario, es imposible que no tenga todo en RAM" > > cuando lo que pasa es que > > "es una aplicacion multiusuario, cuando un usuario interacciona, reificamos > el modelo que se necesita para esa operacion, no tenemos todo en RAM" > > Pero sin tener mas detalles del caso de uso, no sabria decirte que es lo > que hay que tener en RAM, y que es lo que no. > > Una opcion, si es que se te va la vida en tener todo en RAM, es: > > - ante una operacion (una movida, una accion de jugador), modificar el > modelo en memoria (supongo que esta todo en memoria), y grabar en disco el > "delta" del modelo, o simplemente el comando del jugador. > > - cada tanto grabar snapshots del modelo > > - Si se cae la maquina, volver al ultimo snapshot, y aplicarlo los comandos > guardados en el paso 1 > > Pero asi como esta ese "approach" se me ocurren 40 mas, dependiendo DE LOS > CASOS DE USO (es multiplayer de 2, 4, 10000 jugadores, realtime?, etc...) > > Como escribieron en este thread, NHibernate solo te va a ayudar a persistir > y reificar objetos de tu dominio. Que sean los mismos que necesitas para el > juego, que estos esten o no siempre en memoria, depende de todo un contexto > que no podemos deducir de lo que enviaste. > > Nos leemos! > > Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez > > 2012/2/13 BlackCid <[email protected]> > > > > > "yo creo que primero iría por "minimizar" cada request en lugar de > > crear una mega-aplicación en ram. ¿cuál es el costo de acceso a base > > de datos que tenés? " > > > Estamos hablando de un juego multijugador, es imposible que no tenga > > todo en ram... tiene que haber una sesion unicamente si o si, no pude > > haber dos usuarios interactuando con distinta informacion... > > > On 13 feb, 17:45, "[email protected]" <[email protected]> > > wrote: > > > Lo que te recomiendo es que no uses la session de nh como contenedor > > > de objetos desde multiples threads. > > > > Tendrías que analizar bien la arquitectura a utilizar, revisar los > > > ciclos de vida de los objetos... > > > > ...no es recomendable la "Session-per-application" > > > (http://fabiomaulo.blogspot.com/2009/04/empezando-con-nh-session.html) > > > > en tu caso, estarías planteando una "Session-per-time", es decir, que > > > la utilizan todos los hilos un determinado tiempo que ahora es hasta q > > > se te reinicia el app-pool pero creo que podrías buscar algo mas > > > elegante. > > > > Consulta ¿cuántos miles de usuarios esperás que estén haciendo request > > > en mismo momento?... > > > > yo creo que primero iría por "minimizar" cada request en lugar de > > > crear una mega-aplicación en ram. ¿cuál es el costo de acceso a base > > > de datos que tenés? > > > > saludos. > > > nelo > > > > 2012/2/13 BlackCid <[email protected]>: > > > > > No acabo de entender que quieres decir, para controlar el > > > > multithreading he añadido locks y va perfectaente, respecto a lo otro > > > > que os referis, no se si quereis decir que use nhibernate solo para > > > > cargar y guardar y luego traspase esa informacion a objetos separados > > > > de nhibernate. Para eso debería hacer una capa intermedia, pero de la > > > > forma que me la imagino para cada campo de cada clase debería llamar a > > > > un metodo que registrase ese cambio para posteriormente guardarlo en > > > > nhibernate antes de hacer el flush que se realizaría cada X minutos... > > > > ¿eso no cargaría demasiado? > > > > > On 12 feb, 19:26, "[email protected]" <[email protected]> > > > > wrote: > > > >> Hola blacksid, creo que deberías considerar que nhibernate es un ORM, > > > >> nada mas, nada menos. Creo que le estás dando demasiado "protagonismo" > > > >> o "responsabilidades" en tu proyecto. > > > > >> Como dice Carlos, deberías buscar mecanismo que sea apto para para > > > >> multithreading, ese mecanismo, dentro, como ORM, puede usar > > > >> tranquilamente nhibernate, pero la session de nh no es el contenedor > > > >> de objetos adecuado para el proposito que mencionás. > > > > >> saludos. > > > >> nelo > > > > >> > multithreading. > > > > >> 2012/2/12 Carlos Peix <[email protected]>: > > > > >> > Hola blacksid, > > > > >> > Flush auto esta pensado justamente para el caso que mencionas, es > > decir, > > > >> > cuando NH "sospecha" que un query puede alcanzar objetos que tiene > > en > > > >> > memoria con persistencia pendiente, entonces hace un flush a la > > base para > > > >> > que el query traiga ese objeto. > > > > >> > Ahora bien, si tenes una sola sesion de NH en memoria para un juego > > > >> > multijugador y esa sesion esta viva mucho tiempo, me parece que no > > vas por > > > >> > el camino correcto. > > > > >> > A menos que ese juego sea un simple experimento, sugiero que > > trabajes en > > > >> > memoria con esa informacion u otro tipo de mecanismo que sea apto > > para > > > >> > multithreading. > > > > >> > ---------------------------------- > > > >> > Carlos Peix > > > > >> > 2012/2/12 BlackCid <[email protected]> > > > > >> >> A ver, se trata de un juego multijugador, por eso debo usar una > > sesion > > > >> >> todo el rato (digamos que dura infinito, en realidad cada X tiempo > > se > > > >> >> reiniciaría la aplicacion pero bueno), y es por eso que se me > > complica > > > >> >> tanto. Respecto a lo del flush lo que se suele hacer es un flush > > cada > > > >> >> X minutos en este tipo de aplicaciones, por eso no lo pongo auto. > > Aun > > > >> >> debo estudiar como se realiza el flush pero daba por hecho el > > > >> >> realizarlo cada X minutos, a no ser que me recomendeis otra cosa. > > > > >> >> On 11 feb, 16:07, Carlos Peix <[email protected]> wrote: > > > >> >> > Hola blacksid, > > > > >> >> > Por algun motivo estas desestimando la solucion que te propuso > > Nelo mas > > > >> >> > arriba? me refiero a la de configurar el flush en auto. > > > > >> >> > ---------------------------------- > > > >> >> > Carlos Peix > > > > >> >> > 2012/2/11 BlackCid <[email protected]> > > > > >> >> > > A ver el tema es el siguiente, primero hago el query para > > saber si > > > >> >> > > esta el objeto, si no está hago new de un objeto, y le hago un > > save. > > > >> >> > > El tema es que tal vez luego, y solo tal vez, lo necesitaré. > > Se trata > > > >> >> > > de una aplicacion q van interactuando (con la misma sesión), > > asi que > > > >> >> > > no puedo predecir el futuro. > > > > >> >> > > De momento lo que he hecho es hacer una lista de los ids > > creados, no > > > >> >> > > va del todo mal pero bueno si se pudiese usar nhibernate > > directamente, > > > >> >> > > código q me ahorro. > > > > >> >> > > On 10 feb, 20:08, "[email protected]" < > > [email protected]> > > > >> >> > > wrote: > > > >> >> > > > Si, hasta donde recuerdo, si accedes a un objeto con el Get > > y lo > > > >> >> > > > tiene > > > >> >> > > > en cache te trae ese (ya sea por el Save o porque lo > > consultaste > > > >> >> > > > antes > > > >> >> > > > en esa session). El tema no es que no lo encuentre, sino que > > no sabe > > > >> >> > > > si el objeto que está en cache cumple con las condiciones de > > la > > > >> >> > > > query. > > > > >> >> > > > Si nos dieses un poco mas de contexto de lo que estás > > queriendo > > > >> >> > > > hacer, > > > >> >> > > > quizás alguien tenga alguna idea de como solucionarlo. > > > > >> >> > > > saludos. > > > >> >> > > > nelo. > > > > >> >> > > > 2012/2/10 BlackCid <[email protected]>: > > > > >> >> > > > > Entonces la respuesta es No se puede. ¿No? > > > >> >> > > > > De todas formas yo creo que es más por la cache de query, > > porque > > > >> >> > > > > si > > > >> >> > > > > hago un get, (que antes no habia hecho y por tanto no debe > > estar > > > >> >> > > > > en > > > >> >> > > > > caché), de su id lo pilla :-/, así que algo me dice que es > > porque > > > >> >> > > > > primero ejecuto al query, luego hago el save y luego la > > vuelvo a > > > >> >> > > > > ejecutar. Pero intento invalidar la query caché y no parece > > > >> >> > > > > funcionar. > > > >> >> > > > > ¿Que posibilidades tengo para invalidar la caché de query? > > A ver > > > >> >> > > > > si > > > >> >> > > > > estoy intentándolo bien... > > > > >> >> > > > > Aunque a lo mejor tienes razón y ejecuta la query contra > > la base > > > >> >> > > > > de > > > >> >> > > > > datos pero el get si lo coja de su memoria. :S > > > > >> >> > > > > On 10 feb, 04:02, "[email protected]" > > > >> >> > > > > <[email protected]> > > > >> >> > > > > wrote: > > > >> >> > > > >> Seguramente porque tenés el FlushMode en Never o en > > Commit y la > > > >> >> > > > >> query > > > >> >> > > > >> se ejecuta contra la DB... hasta donde recuerdo, > > NHibernate no > > > >> >> > > > >> tiene > > > >> >> > > > >> un motor T-SQL para los objetos en RAM. > > > > >> >> > > > >> Una opción sería que pases a FlushMode Auto y de esta > > forma > > > >> >> > > > >> NHibernate > > > >> >> > > > >> hará automáticamente el Flush cuando detecte que el > > resultado de > > > >> >> > > > >> una > > > >> >> > > > >> query se puede ver afectado por objetos cuyo estado > > todavía no > > > >> >> > > > >> fue > > > >> >> > > > >> reflejado en la DB. > > > > >> >> > > > >> Si vas por el FlushMode en Auto, debés manejar > > correctamente las > > > >> >> > > > >> transacciones y no es compatible con CpBT ni con session > > que > > > >> >> > > > >> duren mas > > > >> >> > > > >> que un request (pensando en una aplicación web). > > > > >> >> > > > >> saludos. > > > >> >> > > > >> nelo > > > > >> >> > > > >> 2012/2/9 BlackCid <[email protected]>: > > > > >> >> > > > >> > Ya, yo estoy hablando desde la misma sesión, pero > > resulta que > > > >> >> > > > >> > hago > > > >> >> > > un > > > >> >> > > > >> > save de dicha entidad, y luego cuando hago una query no > > me > > > >> >> > > > >> > sale. > > > > >> >> > > > >> > On 8 feb, 17:14, "[email protected]" > > > >> >> > > > >> > <[email protected]> > > > >> >> > > > >> > wrote: > > > >> >> > > > >> >> Desde la misma session SI, desde otra NO. El flush es > > > >> >> > > > >> >> justamente el > > > >> >> > > > >> >> "pasaje" de la session a la- Ocultar texto de la cita - > > - Mostrar texto de la cita - -- Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano
