servicios - Gestión de sesión de NHibernate en aplicaciones de servicio de Windows

principales servicios de windows

Question

Estoy desarrollando y aplicación que se ejecuta como un servicio de Windows. Existen otros componentes que incluyen algunos servicios WCF, una GUI de cliente, etc., pero es el servicio de Windows el que accede a la base de datos.

Por lo tanto, la aplicación es un servidor de larga ejecución, y me gustaría mejorar su rendimiento y escalabilidad. Buscaba mejorar el acceso a los datos, entre otras cosas. Publiqué en otro hilo sobre el almacenamiento en caché de segundo nivel.

Esta publicación trata sobre la gestión de sesiones para el hilo de larga ejecución que accede a la base de datos. ¿Debo usar un contexto estático de subprocesos? Si es así, ¿hay algún ejemplo de cómo se implementaría?

Todos los usuarios de NHibernate que están alrededor de la red parecen estar muy centrados en arquitecturas de estilo de aplicaciones web. Parece haber una gran falta de documentación / discusión para diseños de aplicaciones que no sean web.

Por el momento, mi hilo de larga duración hace esto:

1. Llamar a 3 o 4 métodos DAO
2. Verifique el estado de los objetos separados devueltos.
3. Actualice el estado si es necesario.
4. Llame a un par de métodos DAO para conservar las instancias actualizadas. (pase el ID del objeto y la instancia en sí; el DAO recuperará el objeto del DB nuevamente y establecerá los valores actualizados y session.SaveOrUpdate () antes de confirmar la transacción.
5. Dormir durante ''n'' segundos
6. Repite todo de nuevo!

Entonces, el siguiente es un patrón común que usamos para cada uno de los métodos DAO:

• Abrir sesión usando sessionFactory.OpenSession ()
• Comience la transacción
• Do db trabajo. recuperar / actualizar, etc.
• Commit trans
• (Retroceso en caso de excepciones)
• Finalmente siempre deseche la transacción y la sesión.Close ()

Esto sucede para cada llamada de método a una clase DAO. Sospecho que esto es una especie de anti-patrón de la forma en que lo estamos haciendo.

Sin embargo, no puedo encontrar direcciones suficientes en ninguna parte sobre cómo podemos mejorarlo.

Por favor, tenga en cuenta que, mientras este hilo se ejecuta en segundo plano, haciendo sus cosas, hay solicitudes provenientes de los clientes de WCF, cada una de las cuales podría hacer 2-3 llamadas DAO, a veces consultando / actualizando los mismos objetos que trata el hilo de larga ejecución. .

Cualquier idea / sugerencia / puntero para mejorar nuestro diseño será muy apreciada. Si podemos entablar una buena discusión, podríamos hacer de esto una wiki de la comunidad, y posiblemente un enlace aquí desde http://nhibernate.info

Krishna

Answer 1

Parece haber una gran falta de documentación / discusión para diseños de aplicaciones que no sean web.

Esta también ha sido mi experiencia. Sin embargo, el modelo que estás siguiendo me parece correcto. Siempre debe abrir una sesión, confirmar cambios y luego cerrarla nuevamente.

Answer 2

También puede enjuagar la sesión sin cerrarla realmente y logra lo mismo. Hago.

Answer 3

Esta pregunta ya es un poco vieja, pero otra técnica sería usar Sesiones Contextuales en lugar de crear una nueva sesión en cada DAO.

En nuestro caso, estamos pensando en crear la sesión una vez por subproceso (para nuestro servicio win32 de subprocesos múltiples) y ponerla a disposición de los DAO utilizando una propiedad que devuelva SessionFactory.GetCurrentSession () (utilizando el proveedor de sesión actual ThreadContext) , por lo tanto, es sesión por hilo) o vía DI (inyección de dependencia, una vez más usando ThreadContext)

Más información sobre GetCurrentSession y las sesiones contextuales aquí .

Answer 4

Recientemente hemos comenzado a usar un contenedor IoC para administrar el ciclo de vida de la sesión, como un reemplazo para las sesiones contextuales mencionadas anteriormente. (Más detalles aquí ).

Answer 5

Estoy de acuerdo, no hay muchos ejemplos de aplicaciones con estado. Estoy pensando en hacer lo siguiente:

Al igual que usted, tengo un servicio de Windows que aloja varios servicios de WCF. Entonces los servicios de WCF son los puntos de entrada. En última instancia, todos mis servicios WCF heredan de AbstractService, que maneja una gran cantidad de registros e inserciones / actualizaciones básicas de bases de datos.

En una de las mejores publicaciones de NHibernate que he visto, un HttpModule hace lo siguiente: ver http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx

private void BeginTransaction(object sender, EventArgs e) {
NHibernateSessionManager.Instance.BeginTransaction();
}
private void CommitAndCloseSession(object sender, EventArgs e) {
try {
NHibernateSessionManager.Instance.CommitTransaction();
}
finally {
NHibernateSessionManager.Instance.CloseSession();
}
}

Entonces quizás debería hacer algo similar en AbstractService. Entonces efectivamente terminaré con una sesión por invocación de servicio. Si examina el enlace de artículo sobre mejores prácticas de NHib que aparece arriba, verá que el NHibernateSessionManager debería ocuparse de todo lo demás, siempre que abra y cierre la sesión (constructor y destructor de AbstractService).

Solo un pensamiento. Pero estoy experimentando errores debido a que mi sesión parece estar dando vueltas por mucho tiempo, y estoy obteniendo el infame error - NHibernate.AssertionFailure: null id en la entrada (no descargue la sesión después de que ocurra una excepción).