Las estrategias de bloqueo pueden ser de tipo pesimista,
optimista o ninguno. Para elegir la estrategia de bloqueo, debe tener en cuenta cuestiones como el
porcentaje de cada tipo de operaciones que realizará, si utilizará un cargador o no,
etc.
Los bloqueos son enlazados por transacciones. Puede especificar los siguientes valores de bloqueo:
- Sin bloqueo: la ejecución sin el valor de bloqueo es la más rápida.
Si utiliza datos de sólo lectura, es posible que no necesite el bloqueo.
- Bloqueo pesimista: adquiere bloqueos sobre entradas y luego mantiene los bloqueos hasta que se realiza la confirmación. Esta estrategia de bloqueo proporciona una mayor coherencia a costa del rendimiento.
- Bloqueo optimista: toma una imagen anterior de cada registro que toca la transacción y compara la imagen con los valores de entrada actuales cuando se confirma la transacción.
Si los valores de entrada cambian, la transacción se retrotrae. No se mantiene ningún bloqueo hasta el momento de la confirmación. Esta estrategia de bloqueo proporciona una mejor concurrencia que la estrategia pesimista, con el riesgo de que la transacción se retrotraiga y el coste de memoria de realizar una copia adicional de la entrada.
Establezca la estrategia de bloqueo en la BackingMap. No puede cambiar la estrategia de bloqueo para cada transacción. A continuación, aparece un fragmento de código XML de ejemplo que muestra cómo establecer la modalidad de bloqueo en una correlación utilizando el archivo XML, que da por supuesto que
cc es el espacio de nombres para el espacio de nombres de
objectgrid/config:
<cc:backingMap name="RuntimeLifespan" lockStrategy="PESSIMISTIC" />
Bloqueo pesimista
Utilice la estrategia de bloqueo pesimista en operaciones de correlación de lectura y
grabación cuando no es posible utilizar otra estrategia de bloqueo. Cuando se configura una correlación ObjectGrid para utilizar la estrategia de bloqueo pesimista, se obtiene un bloqueo de transacción pesimista para una entrada de correlación cuando una transacción obtiene por primera vez la entrada de BackingMap.
El bloqueo pesimista se
mantiene hasta que la aplicación completa la transacción.
Por lo general, la estrategia de bloqueo pesimista se utiliza en las
situaciones siguientes:
- Cuando BackingMap se configura con o sin un cargador y la información de
creación de versiones no está disponible.
- Cuando BackingMap se utiliza directamente en una aplicación que necesita
ayuda de eXtreme Scale para el control
de simultaneidad.
- Cuando la información de creación de versiones está disponible, pero las
transacciones de actualización colisionan con frecuencia en las entradas de
respaldo, lo cual produce anomalías optimistas de actualización.
Como
la estrategia de bloqueo pesimista tiene el mayor impacto sobre el rendimiento
y la escalabilidad, esta estrategia sólo debe utilizarse para correlaciones de
lectura y grabación, cuando no es viable ninguna otra estrategia de bloqueo.
Por ejemplo, estas situaciones podrían incluir cuando se producen con frecuencia anomalías optimistas de actualización, o cuando es difícil para una aplicación gestionar la recuperación de una anomalía optimista.
Bloqueo optimista
En la estrategia de bloqueo optimista, se presupone que dos transacciones no
pueden intentar actualizar la misma entrada de correlación mientras se ejecutan
simultáneamente. Por este motivo, la modalidad de bloqueo no necesita mantenerse para el ciclo de vida de la transacción, porque
ya que es improbable que más de una transacción actualice la entrada de correlación simultáneamente. Por lo general, la estrategia de bloqueo optimista se utiliza en las
situaciones siguientes:
- Cuando BackingMap se configura con o sin un cargador y la información de
creación de versiones está disponible.
- Cuando BackingMap tiene mayoritariamente transacciones que realizan
operaciones de lectura.
En BackingMap, las operaciones insert, update o remove no se producen con frecuencia en las entradas de correlaciones.
- Cuando una correlación BackingMap se inserta, actualiza o elimina con más
frecuencia de lo que se lee, pero las transacciones rara vez colisionan en la
misma entrada de correlación.
Al igual que en la estrategia de bloqueo
pesimista, los métodos de la interfaz ObjectMap determinan cómo
eXtreme Scale intenta automáticamente
adquirir una modalidad de bloqueo para una entrada de correlación a la que se
accede.
No obstante, las diferencias entre las estrategias optimistas y pesimistas son:
- Al igual que la estrategia de bloqueo pesimista, los métodos
get y getAll adquieren una modalidad de
bloqueo S cuando se invoca el método. Sin embargo, con el bloqueo optimista, la
modalidad de bloqueo S no se mantiene hasta que finaliza la transacción, sino
que se libera antes de que el método vuelva a la aplicación.
El propósito de adquirir la modalidad de bloqueo es que
eXtreme Scale pueda garantizar que sólo
los datos confirmados de otras transacciones sean visibles a la transacción
actual.
Después de que eXtreme Scale haya
comprobado que los datos se han confirmado, la modalidad de bloqueo S se
libera. Durante el ciclo de confirmación, se realiza una comprobación de la
creación de versiones optimista para garantizar que ninguna otra transacción
haya modificado la entrada de correlación después de que la transacción actual
haya liberado su modalidad de bloqueo S. Si no se capta una entrada de la correlación antes de que se actualice, invalide o suprima, el tiempo de ejecución de eXtreme Scale capta de forma implícita la entrada de la correlación. Esta operación get implícita se
realiza para obtener el valor actual en el momento en que la entrada se
solicitó para modificarse.
- A diferencia de la estrategia de bloqueo pesimista, los métodos getForUpdate y getAllForUpdate se manejan exactamente igual que los métodos get y getAll cuando se utiliza la estrategia de bloqueo optimista. Es decir, se adquiere una modalidad de bloqueo S al inicio del método y se libera la modalidad de bloqueo S antes de que se devuelva a la aplicación.
Todos los otros métodos ObjectMap se
manejan exactamente igual que si se manejaran para la estrategia de bloqueo
pesimista.
Es decir, cuando se invoca el método commit, se obtiene una modalidad de
bloqueo X para cualquier entrada de correlación que se inserte, actualice,
elimine, manipule o invalide, y la modalidad de bloqueo X se mantiene hasta que
la transacción complete el proceso de confirmación.
En la
estrategia de bloqueo optimista, se presupone que ninguna transacción que se
ejecute simultáneamente con otra intentará actualizar la misma entrada de
correlación. Por este motivo, la modalidad de bloqueo no necesita mantenerse
durante toda la vida de la transacción ya que es improbable que más de una
transacción actualice la entrada de correlación simultáneamente.
Sin embargo, como no se ha mantenido la modalidad de bloqueo, otra transacción simultánea podría actualizar de forma potencial la entrada de la correlación, después de que la transacción actual haya liberado su modalidad de bloqueo S.
Para manejar
esta posibilidad, eXtreme Scale obtiene
un bloqueo X durante el ciclo de confirmación y realiza una comprobación de la
creación de versiones optimista para verificar que ninguna otra transacción
haya modificado la entrada de correlación después de que la transacción actual
haya leído la entrada de correlación en BackingMap. Si otra transacción ha
modificado la entrada de correlación, se produce una anomalía en la
comprobación de versiones y se muestra una excepción
OptimisticCollisionException. Esta excepción obliga a la transacción actual retrotraerse y la aplicación debe volver a intentar toda la transacción. La
estrategia de bloqueo optimista es muy útil cuando se producen sobre todo
lecturas de una correlación y rara vez se producen actualizaciones de la misma
entrada de correlación.
Sin bloqueo
Cuando un objeto BackingMap se configura para que no use ninguna estrategia de
bloqueo, no se obtiene ningún bloqueo de transacción para una entrada de
correlación.
No usar ninguna estrategia de bloqueo es útil cuando una aplicación es un gestor de
persistencia como, por ejemplo, un contenedor EJB (Enterprise JavaBeans) o cuando una aplicación utiliza Hibernate para obtener los datos persistentes. En
este escenario, BackingMap se configura sin cargador y el gestor de
persistencia utiliza BackingMap como memoria caché de datos. En este escenario,
el gestor de persistencia proporciona control de simultaneidad entre las
transacciones que están accediendo a las mismas entradas de correlación.
WebSphere eXtreme
Scale no necesita obtener ningún
bloqueo de transacción para el control de simultaneidad. Esta situación presupone que el gestor de persistencia no libera sus bloqueos de
transacción antes de actualizar la correlación de ObjectGrid con los cambios confirmados. Si el gestor de persistencia libera sus bloqueos, debe utilizarse
una estrategia de bloqueo optimista o pesimista. Por ejemplo, suponga que el gestor de
persistencia de un contenedor EJB está actualizando una correlación
de ObjectGrid con los datos que se confirmaron en la transacción gestionada por el contenedor EJB. Si la actualización de la correlación de ObjectGrid se produce antes de que se liberen los bloqueos de transacción del gestor de persistencia, podrá utilizar la estrategia sin bloqueos. Si la actualización de la correlación de ObjectGrid se produce después de que se liberen los bloqueos de transacción del gestor de persistencia, debe utilizar la estrategia de bloqueo optimista o pesimista.
Otro escenario
en el que se puede utilizar una estrategia sin bloqueos es cuando la aplicación
utiliza BackingMap directamente y se ha configurado un cargador para la
correlación.
En este escenario, el cargador utiliza el soporte de control de simultaneidad
proporcionado por un sistema de gestión de bases de datos relacionales (RDBMS)
mediante el uso de Java Database
Connectivity (JDBC) o Hibernate para acceder a los datos de la base de datos
relacional.
La implementación de cargador puede utilizar un acercamiento optimista o
pesimista. Un cargador que utiliza un bloqueo optimista o un procedimiento de
creación de versiones favorece un alto nivel de simultaneidad y rendimiento.
Para obtener más información sobre cómo implementar un enfoque de bloqueo optimista, consulte la sección OptimisticCallback
en Configuración de cargadores de base de datos. Si utiliza un cargador que utiliza el soporte de bloqueo pesimista de una programa de fondo subyacente, es posible que desee utilizar el parámetro forUpdate que se pasa en el método get de la interfaz Loader. Establezca este parámetro en true si el método getForUpdate de la interfaz ObjectMap ha sido utilizado por la aplicación para obtener los datos. El cargador puede utilizar este parámetro para determinar si debe solicitar un
bloqueo actualizable en la fila que se está leyendo. Por ejemplo, DB2 obtiene un bloqueo que se puede actualizar si una sentencia SQL select contiene una cláusula FOR
UPDATE. Este
acercamiento ofrece la misma prevención de situaciones de punto muerto que la
descrita en el apartado Bloqueo pesimista.
Para obtener más información, consulte Bloqueos o Gestor de bloqueo.