Cómo resolver el problema de múltiples fuentes de datos en el marco Spring

Lo primero que pensé fue configurar todas las fuentes de datos en el contexto de aplicación de Spring. Estas fuentes de datos pueden ser de diferentes tipos, como diferentes bases de datos: por ejemplo, la fuente de datos proporcionada por apache org.apache.commons.dbcp.BasicDataSource, la org.springframework.jndi.JndiObjectFactoryBean proporcionada por spring, etc. Luego, sessionFactory cambia las fuentes de datos estableciendo la propiedad dataSource en una fuente de datos diferente en cada solicitud del cliente.

Sin embargo, pronto descubrí un problema: cuando varios usuarios acceden simultáneamente a la base de datos al mismo tiempo, se producirán problemas de contención de recursos. Todo esto se debe al "patrón de caso único". Como todos sabemos, estamos usando el marco de primavera, y los beans registrados en beanFactory básicamente usan el modo singleton, es decir, cuando comienza la primavera, estos beans se cargarán en la memoria y cada bean se usará en el. proyecto completo. Sólo existe un objeto. Debido a que solo hay un objeto, todas las propiedades del objeto, o más precisamente, las variables de instancia, se comportan como variables estáticas (de hecho, "estático" y "singleton" tienden a ser dos cosas muy similares que usamos con frecuencia). De hecho, "estático" y "singleton" son a menudo dos cosas muy similares, y a menudo usamos "estático" para implementar "singleton"). En nuestro caso, sessionFactory es el único objeto en todo el proyecto, y su variable de instancia dataSource también es única, al igual que las variables estáticas. Si diferentes usuarios continúan modificando el valor de dataSource, inevitablemente habrá un problema de que varios usuarios compitan por una variable, lo que es un peligro potencial para el sistema.

A través del análisis anterior, la clave para resolver el problema del acceso a múltiples fuentes de datos es que la fábrica de sesiones puede cambiar dinámicamente las fuentes de datos según las necesidades del cliente a través de un fragmento de código al realizar la persistencia de datos y resolver la contención de recursos. asuntos.

Usando el patrón de diseño decorador

Para resolver este problema, mi idea se centra en la fuente de datos. Si la fuente de datos señalada por la fábrica de sesiones se puede conectar a la fuente de datos real requerida por el cliente de acuerdo con las necesidades del cliente, es decir, brindando la capacidad de cambiar dinámicamente las fuentes de datos, entonces el problema se resolverá fácilmente. Entonces, ¿qué hacemos? Para modificar la fuente de datos, ¿utilizamos el código fuente de la fuente de datos? Obviamente, esta no es una buena solución y queremos que nuestras modificaciones estén separadas del código fuente de datos original. Según el análisis anterior, utilizar el patrón decorador en el patrón de diseño GoF debería ser la mejor opción que podamos elegir.

¿Qué es el patrón decorador? En pocas palabras, cuando necesitamos modificar la función original pero no queremos modificar directamente el código original, diseñamos un Decorador fuera del código original. Cuando usamos Decorator, es exactamente lo mismo que usar la clase original, excepto que cuando algunas funciones en Decorator se modifican a las funciones que necesitamos modificar. La estructura del patrón Decorador se muestra en la figura.

Originalmente necesitábamos modificar algunas funciones de todas las clases de componentes específicas en el diagrama, pero no modificamos su código directamente, sino que agregamos un decorador fuera de ellas. Esto significa que cuando usamos Decorator, estamos usando ConcreteComponentA o ConcreteComponentB, e incluso aquellos programas cliente que usan ConcreteComponentA o ConcreteComponentB no saben que la clase que están usando ha sido cambiada a Decorator, pero Decorator ha modificado algo de la clase Component específica. Algunos métodos y los resultados de ejecutar estos métodos son diferentes.