Preguntas frecuentes sobre afinidad de sesiones y persistencia de sesiones

¿Debe estar habilitada la afinidad de sesiones al escalar horizontalmente los servidores de aplicaciones?

Sí.

¿Debe haber persistencia de sesiones al escalar horizontalmente los servidores de aplicaciones?

A no ser que sus requisitos de negocio hagan especial hincapié en tener conmutación por error transparente en las raras circunstancias en que la persistencia de sesiones puede suponer una diferencia, Sun desaconseja el uso de persistencia de sesiones. La persistencia de sesiones produce un deterioro específico del rendimiento, por lo que conviene prescindir de ella salvo que los requisitos de negocio impongan a toda costa la conmutación por errores transparente.

Si analiza las situaciones expuestas en Escenarios de fallos, comprobará que seis de los casos no presentan ninguna diferencia en cuanto a la experiencia del usuario o las acciones de recuperación necesarias, con independencia de que esté habilitada la persistencia de sesiones. Sólo los escenarios 1 y 4 presentan diferencias en los casos con y sin persistencia de sesiones.

En ambos escenarios, la persistencia de sesiones puede aportar cierta transparencia a la conmutación por error, pero siempre a costa del rendimiento. Según el tamaño de los objetos de sesión, el depósito utilizado para la persistencia de sesiones y la optimización del código de administración de sesiones del servidor de aplicaciones específico, el rendimiento puede resultar perjudicado entre un 10% y un 20%, o incluso más.

¿Debe haber varias instancias de servidor de aplicaciones en un clúster al escalar horizontalmente?

No hay ninguna necesidad de tener varias instancias de servidor de aplicaciones salvo que se quiera persistencia de sesiones. Se puede conseguir conmutación por error sin persistencia de sesiones incluso aunque todos los nodos de servidor de aplicaciones no se encuentren en un clúster.