Mm... ¡gracias por esmerarte tanto en la respuesta! Creo haber entendido las tres alternativas, creo que usaré la segunda, si no he entendido mal sería separar los objetos de NHibernate de los que realmente use, para usar los de Nhibernate solo para cargar/ guardar no?
Lo único es gestionar bien si dos piden el mismo objeto, es decir, si uno me pide el objeto A, y otro pide el objeto A, lo suyo es que ambos apunten al mismo objeto (porque si no las modificaciones de uno noa fectarian al otro), esto no pasa mucho en el juego, pero podría pasar. Para esto podría crear una lista de los objetos, lo dificil sería averiguar cuando ambos dejan de usar dicho objeto (dado que estaría en la lista, no se llamaría al recolector de basura y este no podría avisarme para borrarlo de la lista xD), asi que supongo que debería explícitamente cuando vaya a dejar de usar algo indicarlo con una especie de "dispose" que avisara a la lista de que ese ha dejado de usarlo, y tener una lista o un contador. Mmmm... es muy explícito pero creo que no hay otra. No se, ¿que os parece? Gracias por contestar :). On 13 feb, 20:43, Angel Java Lopez <[email protected]> wrote: > Ah!... > > leer más » > > Bien, entonces el approach que aconsejaria primero es: > > - Tener todo en memoria > - Separar las consultas (que no modificarian el dominio) de los comandos > (que modificarian el dominio) > - Programar que todas las operaciones de lecturas puedan ser concurrentes > - Programar que solo un comando pueda estar siendo resuelto contra el > dominio > > y tres alternativas. Primera: > - Grabar el comando, o el resultado del comando (no se, movida de jugador x > con resultado y), en un archivo > - Grabar el snapshot del dominio en memoria, cada tanto (impidiendo > comandos, tomalo como un comando > - Al levantar la maquina, leer el snapshot, y aplicarle los comandos o > resultados de los comandos, para volver al ultimo estado > > Segunda: > - Si un comando modifica el dominio, grabar los objetos modificados con > NHibernate > - Entonces, todo el dominio siempre esta en memoria, y a la vez, en la base > que maneja el NHibernate > > Tercera: > - Olvidar la persistencia por ahora, programar todo en memoria, con TDD > - Si queres tener una demo online, grabaria cada tanto un snapshot del > dominio, pero no conozco el tamanio que puede llegar a tener > - Solo despues de tener aceptacion, experiencia de usuario, etc... me > ocuparia de la persistencia > - Pensaria quizas en Redis+Azure > - Jejej... yo lo haria usando AjKeyvs... pero no tengo persistencia todavia > > Otras sugerencias? > > Nos leemos! > > Angel "Java" Lopezhttp://www.ajlopez.comhttp://twitter.com/ajlopez > > 2012/2/13 BlackCid <[email protected]> > > > > > 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,- > > > > > >> >> > > > 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
