En mi caso y por el hecho de que no tenia un manejador de conversacion cuando lo hice, cada control en el presenter comienza una session (thread local) cuando empieza el trabajo y la cierra al terminar. Todas las llamadas durante ese caso de uso usan la session que se abrio.
En el ultimo tiempo por diversas razones tuve que pasar a WCF y entonces en lugar de empezar la session en el presenter lo hago con contexts de WCF, y funciona igual (o muy parecido) que un session per request de Web (uso percall y no persession). Con la conversation de uNHaddins todo es un poco mas sencillo ya que cada presenter que inicia su conversacion trabaja con su thread local. Ahora cuando trabajo con threads y si la operacion necesita actualizar la pantalla como te dije, trato de que las llamadas sean en el thread del GUI. Voy a probar luego a fondo y subir a mi ejemplo de session management como funcionaria esto con la conversacion de uNHAddins... Luego te cuento y discutimos lo que hice ok? Saludos. Gustavo. 2009/1/12 Diego Jancic <[email protected]> > Parece ser una buena idea, en realidad como es un proyecto chico y las > bases de datos son muy chicas podría implementar cualquier método por mas > malo que sea (siempre y cuando sea fácil) > > Como definís el scope de cada session? En web puedo usar el HttpContext > que, encapsulado adecuadamente, me permite que muchos repositorios llamados > desde diferentes lugares usen la misma session. > > > > Lo único que se me ocurre es definirlo a nivel thread. Pero hay problemas > si hay mas de un control, a menos que la duración de cada session sea lo que > dure el método. Mas claro con un ejemplo. > > > > Podes hacer esto: > > > > private void UnMetodo() > > { > > InitWorkSpace(); > > // Work > > CloseWorkSpace(); > > } > > > > Pero no podes hacer eso: > > > > public Constructor() > > { > > InitializeComponent(); > > InitWorkSpace(); > > } > > > > Public void Dispose() > > { > > CloseWorkSpace(); > > } > > > > Me equivoco? > > > > Gracias! > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gustavo Ringel > *Sent:* Sunday, January 11, 2009 04:56 > > *To:* [email protected] > *Subject:* [NHibernate-Hispano] Re: Conversaciones y Threads > > > > Porque no pones en UserControls cada unidad que puede actualizar algo > distinto y actualizas solo ese user control y no todo el form? Para mi un > form es solo un container....todo lo que trabaja es user controls. > > Por ejemplo en el sistema actual en la pantalla muestro una lista con todos > los items esperando a ser procesados, y a la derecha una lista de > operadores, arriba cierta informacion de configuracion que dice si las > maquinas asociadas a mi pantalla estan ahora libres, si el operador piensa > deslogearse de aqui a poco, etc. > > Cada control tiene su propio ciclo de vida, maneja su propia sesion y se > comunican entre ellos solo por eventos...Cada control maneja un bloque de > informacion que no tiene nada en comun a la hora de trabajar con los demas y > lo que necesita en comun (cambios) lo recibe por los eventos (por ejemplo > quien es el operador actual) > > Gustavo. > > 2009/1/11 Diego Jancic <[email protected]> > > Hola, > > Gustavo, tenes razon en eso… y hoy a la tarde comprobe que ya se estaba > usando el mismo thread (porque el "servicio" en realidad es un framework mio > que ya soporta Invoke para que no haya problema con los controles). De todas > formas no me esta funcionando bien Burrow en ese momento. Cuando lo vea de > nuevo les comento, porque posiblemente no pase por ahi el tema. > > > > En realidad mi pregunta era como lo debería manejar un caso asi, porque > estaría actualizando la misma pantalla utilizando 2 sessions diferentes, y > hacer esto significa que las 2 sessions pueden tener informacion diferente > (porque no hicieron el flush, porque no hay transacciones cerradas, cache de > 1er nivel, etc…). Ademas a esto se le suma que en WinForms el ciclo de vida > de las sesiones es mas largo, y que no se muy bien como manejar Sessions en > WinForms (estoy siguiendo algunos guidelines de Fabio, o mejor dicho lo que > entendí de esos guidelines) J > > > > Saludos! > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Gustavo Ringel > *Sent:* Sunday, January 11, 2009 04:12 > *To:* [email protected] > *Subject:* [NHibernate-Hispano] Re: Conversaciones y Threads > > > > Si estas adentro del from podes usar invoke y ejecutar en el thread del > GUI...eso se hace en general para actualizar controles ya que es la unica > forma, pero bueno, podes asociar tambien la conversacion al thread del > Form... > > > > Gustavo. > > 2009/1/11 Diego Jancic <[email protected]> > > Hola gente!, > > (Escenario: WinForms + NH Trunk + 1era vez con Burrow) > > Lo que necesito hacer es que un Form llame a un servicio de forma > asincrónica, y cuando se ejecuta el callback se actualice informacion. > > El problema es que el Form tiene una conversación de Burrow, y cuando el > servicio asincrónico realiza el Callback lo esta haciendo en un nuevo > thread. Por ese motivo no estoy en la misma conversación y todavía no > encontré forma de unirme a la otra. > > > > Deberia andar si algo asi? : > > (simplificado) > > > > Guid currentConversation; > > void UnMetodoDelForm() > > { > > currentConversation = new BurrowFramework().CurrentConversation.Id; > > > > LlamarAlServicio(callback); > > } > > private void callback (object sender, EventArgs args) > > { > > new BurrowFramework().InitWorkSpace(currentConversation); > > > > // Cosas con la misma session. > > } > > > > Gracias & Saludos!, > > Diego > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
