Conceptos Clave de Persistencia y Arquitectura de Sistemas para Desarrolladores

Conceptos Fundamentales de Persistencia y Arquitectura de Sistemas

Pool de Conexiones

Un Pool de Conexiones es un conjunto limitado de conexiones a una base de datos (BD) que es manejado por un servidor de aplicaciones. De esta forma, dichas conexiones pueden ser reutilizadas por los diferentes usuarios. Es administrado por un servidor de aplicaciones que va asignando las conexiones a medida que los clientes van solicitando consultas o actualizaciones de datos.

Arquitectura de Aplicaciones

La arquitectura de aplicaciones se suele dividir en capas:

• Capa de Presentación: Gestiona la interfaz de usuario.
• Capa de Negocio: Implementa la lógica de negocio y las reglas que deben cumplirse.
• Capa de Datos: Se comunica con otros sistemas para enviar/recibir información. Normalmente, interactúa con un Sistema Gestor de Bases de Datos (SGBD) para conseguir la persistencia.

JQL y Método find() en Persistencia

En el contexto de la persistencia:

• Una consulta JQL (Java Persistence Query Language) devuelve una lista de resultados de la clase solicitada en la consulta con getResultList() o un único resultado con getSingleResult().
• El método find() busca por clave primaria (PK), utilizando las propiedades específicas. Si la instancia de la entidad está contenida en el contexto de persistencia, se devuelve desde allí.

Mapeo de Relaciones en JPA

Para el mapeo de relaciones en JPA:

• @OneToMany y @ManyToOne: Se utiliza @OneToMany en el extremo "uno" de la relación (donde se define el Set) y @ManyToOne en el otro extremo. En @OneToMany, es importante indicar (mappedBy="nombreAtributoEnLaManyToOne").
• @ManyToMany: Se utiliza @ManyToMany en ambos extremos de la relación. Se tendrán dos Set, y se pondrá el mappedBy en uno de ellos.

Nota: Si no se indica mappedBy, se interpreta como dos asociaciones unidireccionales separadas.

API de JPA: Componentes Clave

La API de JPA se compone de varios elementos fundamentales:

• EntityTransaction: Se encarga de gestionar la conexión con el SGBD para la persistencia y de administrar las transacciones.
• EntityManagerFactory: Encargada de crear y gestionar el EntityManager.
• EntityManager: Encargado de gestionar la persistencia de objetos.
• Query: Se encarga de la gestión de las consultas.

Inconsistencias en Bases de Datos NoSQL

Las bases de datos NoSQL presentan ciertas características en cuanto a consistencia:

• Menos maduras: En comparación con las bases de datos relacionales.
• Atomicidad elemental: A menudo sin transacciones ACID completas, o con transacciones de bajo nivel.
• Funcionalidad típica limitada: Pueden carecer de algunas características avanzadas de las bases de datos relacionales.
• No hay control de seguridad/integridad: El control de seguridad e integridad de datos puede ser más limitado o recaer en la aplicación.
• Consultas elementales o sin lenguaje específico: Los lenguajes de consulta pueden ser menos potentes o estandarizados.

Consistencia Eventual

En la Consistencia Eventual, los datos se vuelven consistentes pasado un tiempo. Se permite inconsistencia en la replicación entre nodos, pero eventualmente todos los nodos estarán actualizados.

Teorema CAP

El Teorema CAP establece que un sistema distribuido no puede garantizar simultáneamente las tres características siguientes:

• Consistencia (C): Todas las respuestas a los clientes son correctas y reflejan el último dato escrito.
• Disponibilidad (A): El nodo responde a todas las solicitudes, incluso si algunos nodos están caídos.
• Tolerancia al Particionado (P): El sistema, aunque particionado por un fallo de red, sigue respondiendo.

Según el teorema, un sistema distribuido solo puede garantizar dos de estas tres características a la vez.

Quorum en Sistemas Distribuidos

El concepto de Quorum es fundamental en sistemas distribuidos para asegurar la consistencia:

• Quorum de Lectura (R): Número de nodos a contactar para estar seguros de leer el dato actualizado.
• Quorum de Escritura (W): Número de nodos que deben participar en la escritura para que esta se considere exitosa.

Donde n es el factor de replicación (número de copias del dato).

Para asegurar la consistencia, se suele cumplir la condición: R + W > n.

Un ejemplo común es un quorum de escritura W > n/2.

Entidad vs. Value Type (Tipo de Valor)

• Entidad

  Representa un concepto del dominio. Se puede asociar a otras entidades y tiene un ciclo de vida independiente.

• Value Type (VT)

  Representa información adicional, no conceptos principales. Es un atributo de una entidad. Su ciclo de vida depende de la entidad y no puede tener referencias entrantes. Los métodos se deben definir sobre la clave natural de las Entidades y sobre todos los atributos en los Value Types.

Alternativas de Distribución de Datos

Existen varias estrategias para la distribución de datos:

• Servidor Único: La opción más sencilla, donde todos los datos residen en un solo servidor.
• Fragmentación (Sharding): Consiste en fragmentar los datos y repartirlos entre múltiples servidores.
• Replicación (Esclavo-Maestro): Un servidor maestro gestiona las escrituras y los servidores esclavos replican los datos del maestro para lecturas y redundancia.

Niveles de Aislamiento (Transacciones)

Los niveles de aislamiento definen cómo las transacciones concurrentes interactúan entre sí, previniendo diferentes tipos de violaciones:

• Read Uncommitted: Permite los tres tipos de violaciones de aislamiento (lectura sucia, lectura no repetible, fantasmas). (Ej: MySQL)
• Read Committed: Evita la lectura sucia. (Ej: Oracle, PostgreSQL, MySQL)
• Repeatable Read: Evita la lectura sucia y la lectura no repetible. (Ej: MySQL)
• Serializable: Evita todas las violaciones de aislamiento. (Ej: Oracle, PostgreSQL, MySQL)

Relación Many-to-One en Java (UML)

En Java, una relación de muchos a uno con clave compuesta se representa como una clase más, mapeada con una relación de muchos a uno y una clave compuesta.

Estados de un Objeto en JPA

Un objeto gestionado por JPA puede pasar por diferentes estados:

• Transient: Objeto recién creado y aún no enlazado con la base de datos. Únicamente existe en la JVM.
• Persistent: Objeto que ha sido enlazado con la sesión de la base de datos u obtenido de la misma. Todos los cambios que se realizan en el objeto también se reflejan en la base de datos.
• Detached: Objeto que se obtiene al terminar la sesión. Existe en Java y en la base de datos, pero los cambios no se realizan en ambos sitios a la vez, ya que la sesión ha sido cerrada.

Patrones de Diseño para Obtención de Datos (find())

Para la obtención de datos, se pueden aplicar patrones como:

• Command
• Modelo de Dominio
• Service Layer
• Factory Method

Acceso a Averías en Contexto de Sesión

Como se está dentro de un comando, la sesión aún está abierta y, por lo tanto, el grafo de la base de datos está cargado. Así pues, el objeto vehículo estará en estado Persistent y se podrá acceder a getAverias().

Recomendación para Carga de Averías (Action Code)

Necesitarás llamar al adminService para que este obtenga la lista de averías a través de un comando, ya que actualmente el objeto vehículo que tienes no tiene los objetos avería cargados en su getAverias().