Bloqueo optimista

El bloqueo optimista le permite reducir el nivel de aislamiento que utiliza en una aplicación, de forma que se colocan menos bloqueos en los elementos de base de datos. Permite que se puedan ejecutar más aplicaciones simultáneamente contra la base de datos y aumenta, potencialmente, el rendimiento de las aplicaciones.

Importante: De forma predeterminada la mayoría del código de HCL Commerce ejecuta consultas de base de datos en niveles de aislamiento especificados que están dentro de las tolerancias seguras para esas consultas individuales. Puede garantizar el rendimiento óptimo del sitio al establecer el nivel de aislamiento predeterminad para WebSphere Application Server en Cursor Stability. Para más información sobre cómo establecer el nivel de aislamiento predeterminado para WebSphere Application Server, consulte Changing the default isolation level for non-CMP applications and describing how to do so using a new custom property webSphereDefaultIsolationLevel.

Para proteger de los problemas potenciales de integridad de base de datos que puede acarrear la reducción del nivel de aislamiento, una implementación de bloqueo optimista tiene que asegurar que no se producen problemas de integridad. La implementación de HCL Commerce utiliza una columna de predicado optimista para cada tabla en la base de datos OPTCOUNTER de HCL Commerce. Esto ayuda a asegurar que cada vez que haya un cambio en la base de datos, el predicado optimista puede:

Actualizarse con un nuevo valor
Comprobarse si ha cambiado

De esta manera, la implementación puede garantizar que una fila de la base de datos no ha cambiado entre el momento en que se ha leído y el momento en que se ha grabado, para proteger la integridad de la base de datos.

Con esta nueva libertad que ofrece el bloqueo optimista, de colocar menos bloqueos en la base de datos, durante un periodo de tiempo más corto, debe tenerse presente que también puede haber desventajas.

Una estrategia de bloqueo pesimista significa evitar las consecuencias de bloqueo optimista colocando bloqueos en la base de datos. En otras palabras, el bloqueo pesimista supone que se producirán colisiones en la base de datos y toma precauciones para evitar estas colisiones. Una estrategia de bloqueo pesimista protege la integridad de la base de datos bloqueando elementos de base de datos durante todo el tiempo que dura una transacción, desde el principio hasta el final. Durante este periodo, ninguna otra transacción puede acceder a los mismos elementos porque éstos están bloqueados. Esta estrategia proporciona mayores tiempos de espera para más transacciones. También genera la posibilidad de que estas transacciones excedan el tiempo de espera o, potencialmente, entren en un punto muerto.

Una optimistic locking strategy puede mejorar la ejecución de la aplicación al reducir la ventana en que pueden producirse estas consecuencias pesimistas. Al mismo tiempo, abre la posibilidad de colisiones en las que dos o más transacciones intentan actualizar la misma fila en la base de datos. Cuando esto ocurre en una estrategia de bloqueo optimista, pueden producirse retrotracciones (o errores) en una o más de las transacciones (o en todas ellas).

HCL Commerce utiliza un esquema de bloqueo optimista que permite reducir el nivel de aislamiento de transacción de base de datos de lectura repetible a lectura comprometida. Mediante el uso de ese esquema, las filas de base de datos a las que no se accede normalmente de forma simultánea no se bloquean con un intento de actualización cuando se leen. En lugar de ello, cuando finalmente se realiza la actualización, se comprueba la fila para asegurarse de que no se ha actualizado de forma simultánea desde que se ha leído. Si se ha actualizado de forma simultánea, la transacción se retrotrae y el mandato puede reiniciarse desde el principio en un nueva transacción, si es apropiado. En este esquema, mejora el rendimiento cuando normalmente no se producen actualizaciones simultáneas, porque se evita el proceso relativamente costoso de obtener los bloqueos de base de datos con la intención de realizar una actualización. Por otra parte, para las operaciones en las que es más probable que se produzcan actualizaciones simultáneas, se continúa utilizando el bloqueo pesimista, por medio del cual se obtienen bloqueos de intento de actualización cuando se lee una fila, evitando de este modo el proceso más costoso de retrotracción y reinicio desde el principio en una nueva transacción.

Para obtener más información, consulte OptCounterInfo.

Para que el bloqueo optimista funcione correctamente, cada consulta que actualiza una fila de tabla de base de datos debe incrementar el valor de la columna OPTCOUNTER, o restablecerla en 1 cuando el valor actual es 32767. El servidor de HCL Commerce utiliza esta técnica. Sin embargo, si las filas de las tablas de bases de datos se actualizan mediante otro código u otros procedimientos manuales que no actualizan los valores de la columna OPTCOUNTER, los desencadenantes de base de datos definidos en los archivos de esquema de utilities_root/schema/9.0.0.0/db_type/wcs.perf.trigger.sql garantizan que los valores de la columna OPTCOUNTER se incrementen correctamente.

La capa de servicios de datos soporta un mecanismo denominado control de concurrencia optimista (OCC) que es similar en función e implementación al bloqueo optimista utilizado por los EJB en HCL Commerce. OCC se implementa para la mayoría de las tablas de HCL Commerce de forma predeterminada, por razones de rendimiento. No se recomienda cambiar el uso de OCC de estas tablas.

Cuando añade tablas al esquema de HCL Commerce, puede elegir utilizar también la funcionalidad OCC. Debe definir una columna de colisión llamada OPTCOUNTER en la definición de la tabla. La columna OPTCOUNTER debe ser de tipo SMALLINT o INTEGER. La Capa de servicios de datos actualiza la columna de contador de colisiones automáticamente. Cuando hay una colisión durante una operación de guardar, se genera una excepción.

Nota: Si el código personalizado utiliza el bean de acceso para actualizar tablas relacionadas con pedidos y recibe una excepción de bloqueo optimista, puede ser posible que esto se deba a que un procedimiento almacenado listo para utilizar ha alterado el mismo registro en la misma transacción. Para solucionar el problema, el código personalizado debe llamar primero al gestor de entidades para renovar la entidad del bean de acceso antes de actualizarlo.

Nota: Es posible que el bean de entidad que se desvincula del gestor de entidades haga que el código personalizado utilice el bean de acceso para actualizar alguna tabla de base de datos, pero esto no es persistente en la base de datos. Puede llamar al gestor de entidades para renovar la entidad y confirmar que este es el problema. Si el bean de acceso está desconectado, el gestor de entidades generará una excepción que indica que la entidad se ha desconectado al solicitar la actualización. El código personalizado debe llamar al método de fusión del gestor de entidades para volver a conectar el bean de acceso al gestor de entidades para resolver este problema.

Opciones de configuración de MemberLock

Debido a los puntos muertos de la base de datos, los clientes pueden ver mensajes de error al intentar iniciar sesión. Debe modificar el código personalizado para impedir el uso de UserAccessBean. En su lugar, utilice UserDataBean o los beans entregados por el método WCDataCache.newUserAccessBean (si está disponible). También debe habilitar la serialización utilizando la configuración de HitAndMiss, que se explica a continuación. Por último, al habilitar la serialización en la operación, debe ejecutar validaciones de pruebas funcionales y de rendimiento utilizando cargas de tareas de alto volumen realistas.

Todas las solicitudes para una sesión de usuario específica se envían al mismo servidor cuando la afinidad de sesiones está habilitada. A veces se pueden evitar los puntos muertos al serializar todas las hebras que leen un EJB de usuario específico (excepto el usuario genérico, con el ID -1002).

Al adquirir bloqueos Java, la memoria caché de datos HCL Commerce se utiliza para obtener la entrada a los objetos EJB de usuario, independientemente de si la memoria caché de datos está habilitada o no. Para sacar provecho de esta característica, el código personalizado, como un mandato Logon personalizado, debe evitar utilizar la clase UserAccessBean directamente y, en su lugar, utilizar la clase UserDataBean o utilizar WCDataCache.newUserAccessBean si está disponible.

Esta característica de serialización puede estar activada o desactivada y está inhabilitada de forma predeterminada. La funcionalidad se puede activar añadiendo la siguiente opción a la etiqueta wc-server.xml del archivo de configuración de instancia <InstanceProperties>:

<OptimisticLockingSelectForUpdate
com.ibm.commerce.user.beans.MemberLock.HitAndMiss="enabled"
/>

La configuración anterior hace que la memoria caché de datos obtenga el bloqueo de Java en las memorias caché, los aciertos de memoria caché y en los fallos de memoria caché. Se puede dar un valor alternativo para mejorar la simultaneidad, pero con mucha menos seguridad ante posibles punto muertos:

<OptimisticLockingSelectForUpdate
com.ibm.commerce.user.beans.MemberLock.Miss="enabled"
/>

El bloqueo de Java solo se obtiene si hay un fallo de memoria caché con la configuración anterior.

La serialización de hebras puede hacer que las hebras se cuelguen si las hebras implicadas mantienen recursos, como bloqueos de base de datos. El bloqueo Java ofrecido en este parche incluye protecciones.

La primera característica de seguridad es que, a lo largo de una transacción de base de datos, cada hebra esperará bloqueos de hasta 10 segundos. Si se sobrepasa el umbral de 10 segundos, este hebra no podrá obtener bloqueos para la transacción restante y puede producirse el error de concurrencia optimista o punto muerto original.

La segunda característica de seguridad es que los bloqueos Java se liberan automáticamente después de retenidos durante 60 segundos. Debido a ese tiempo de espera de 60 segundos, es posible que otra hebra pueda obtener el bloqueo y ejecutarse simultáneamente con la hebra que retenía el bloqueo antes de su caducidad, y puede producirse la excepción de concurrencia optimista o punto muerto original.

La funcionalidad se puede activar añadiendo la siguiente opción a la etiqueta wc-server.xml del archivo de configuración de instancia <InstanceProperties>:

<com.ibm.commerce.user.beans.MemberLock threshold="10"
timeout="60" />