5. Estrategia Optimistic Locking (@version)

<< Anterior - Volver Menu JPA

La estrategia Optimistic Locking es utilizada cuando se presenta perdida de los efectos de la primera de las transacciones, este problema es mas conocido con el nombre de second lost update.

Las transacciones que lanzan mas de una vez una misma consulta, tiene que implementar un nivel de aislamiento mayor, por lo tanto, esta estrategia es la mas recomendada por Hibernate, ya que maximiza la eficiencia, a menor nivel de aislamiento menos bloqueo en la Base de Datos. Ademas por ser la mas adecuada para la mayor parte de las transacciones.

Para implementar este tipo de estrategias en nuestras aplicaciones se debe añadir un atributo o propiedad de nombre "version" en las entidades modificables, de tipo de variable short, int, long, sus contrapartidas objetuales y java.sql.Timestamp, a demas anotandola con "@version".

¿Como funciona la variable anotada con @version?
Cada vez que se actualiza una instancia de una entidad, Hibernate comprueba si el atributo version coincide con su valor actual, de esta manera: si es afirmativo, osea si devuelve 1, se actualizo la fila y de esta manera no hay conflictos con otra transaccion y la variable version se incrementa de a uno en la fila y en la instancia Account en memoria; en el otro caso, se devuelve 0, de esta forma se lanza una excepcion Runtime, lo que quiere decir es que la fila no se actualizo o que otra transaccion actualizo antes esa fila, en este caso mostraria las siguientes dos excepciones org.hibernate.StaleObjectStateException o org.hibernate.StaleStateException.

En taylor podemor agregar esa anotacion a una entidad de la siguiente manera:

  • Se crea una propieda en la entidad de nombre "version", aclaramos que no es necesario que tenga que ser ese mismo nombre, lo que si es obligatorio que esa propiedad este anotado con el estereotipo @version.
  • Se selecciona en la parte del navegador de objetos o de ficheros el atributo version que se encuentra en la entidad en la cual uste la genero.
  • Se dirige a la parte inferior de la ventana de eclipse donde se encuentra las propiedades del objeto y seleccionamos la pestaña "General", le damos clic en el boton que se encuentra al final del campo type, se distingue por que tiene unos puntos suspensivos.
  • A continuacion se abre una ventana, escribimos y seleccionamos el tipo adecuado para esta propiedad, lo cual se mensionó anteriormente.
  • En esa misma parte seleccionamos la pestaña Stereotype, seleccionamos el estereotipo version en el contenedor de nombre Available Stereotypes y damos en el boton "Add»".

El resultado de los pasos anteriores los podemos observar en la siguiente imagen:

perspectivaTaylor10.JPG

Acontinuacion veremos un ejemplo en lenguaje java, en donde se implementa la estrategia Optimistic Locking:

Clase Entidad Persona.class:

@Entity
public class Persona extends LogAudit implements Serializable, Cloneable{
    /** @generated */
    private static final long serialVersionUID = 1L;

    /** @generated */
    public Persona() {
    }

    *
    *
    *    Mas Código.
    *
    *

    @Version
    // Propiedad que implementa la estrategia Opitmistic Locking.
    public Long getVersion() {
        return version;
    }

    /** @generated */
    public void setVersion(final Long version) {
        this.version = version;
    }

    /** @generated */
    private Long version = null;

    *
    *
    *    Mas Código.
    *
    *

}

Al momento de mapearse la entidad anterior que estamos utilizando como ejemplo se generar con el campo de nombre version que hemos agregado a la entidad, esto lo podemos apresiar en la siguiente imagen:

mapeoBD25.JPG

En la siguientes dos imagen podemos ver un ejemplo de como este tipo de estrategia ayuda a solucionar el problema second lost update:

ejemplo2.JPG

En la anterior imagen podemos observar el problema antes identificado, y que en ejemplo hay dos transacciones concurrentes cuando la segunda transacción hace commit se pierde el efecto de la primera transacción. Observe a continuación la segunda imagen:

ejemplo.JPG

Lo que podemos concluir con la anterior imagen es:

  • No realiza un bloqueo especial sobre las filas que se leen durante la transacción.
  • Retrasa al final de la transacción la comprobación de si hubo conflictos con otras transacciones.

<< Anterior - Volver Menu JPA

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License