Utilización de sesiones para acceder a los datos de la cuadrícula

Las aplicaciones pueden empezar y terminar transacciones a través de la interfaz Session. La inetrfaz Session también proporciona acceso a las interfaces ObjectMap y JavaMap basadas en la aplicación.

Todas las instancias de ObjectMap o JavaMap están unidas a un objeto Session determinado. Cada hebra que desea acceder a un eXtreme Scale debe, en primer lugar, obtener una sesión del objeto ObjectGrid. Una instancia de Session no puede compartirse de modo concurrente entre las hebras. WebSphere eXtreme Scale no utiliza ningún almacenamiento local de hebras, pero las restricciones de plataforma podrían limitar la oportunidad de pasar una sesión de una hebra a otra.

Métodos

Método get

Una aplicación obtiene una instancia de Session de un objeto ObjectGrid utilizando el método ObjectGrid.getSession. El siguiente ejemplo demuestra cómo utilizar una instancia de Session:

ObjectGrid objectGrid = ...; Session sess = objectGrid.getSession();

Después de obtener una Session, la hebra mantiene una referencia a la sesión para uso propio. Si se llama al método getSession varias veces se devolverá una nuevo objeto Session cada vez.

Transacciones y métodos Session

Una Session puede utilizarse para iniciar, confirmar o retrotraer transacciones. Las operaciones realizadas en BackingMaps utilizando ObjectMaps y JavaMaps se realizan con mayor eficacia dentro de una transacción de Session. Después de que se haya iniciado una transacción, cualquier cambio a una o más BackingMaps de ese ámbito de transacción se almacenan en una memoria caché de transacciones especial hasta que se confirme la transacción. Cuando se confirma una transacción, los cambios pendientes se aplican a las BackingMaps y los cargadores y se hacen visibles a los demás clientes ObjectGrid.

WebSphere eXtreme Scale también soporta la capacidad de confirmar automáticamente transacciones, también se conoce como confirmación automática. Si se realiza cualquier operación de ObjectMap fuera del contexto de una transacción activa, se inicia una transacción implícita antes de la operación y la transacción se confirma automáticamente antes de devolver el control a la aplicación.

Session session = objectGrid.getSession();
ObjectMap objectMap = session.getMap("someMap");
session.begin();
objectMap.insert("key1", "value1");
objectMap.insert("key2", "value2");
session.commit();
objectMap.insert("key3", "value3"); // auto−commit

Método Session.flush

El método Session.flush sólo tiene sentido cuando se asocia un cargador a una BackingMap. El método flush invoca el cargador con el conjunto de cambios actuales de la memoria caché de transacciones. El cargador aplica los cambios al programa de fondo. Estos cambios no se confirman cuando se invoca el desecho. Si una transacción de Session se confirma después de una invocación de desecho, sólo las actualizaciones que ocurran después de esa invocación se aplican al cargador. Si una transacción de Session se retrotrae después de una invocación de desecho, los cambios desechados se descartan junto con los demás cambios pendientes de la transacción. Utilice el método Flush con moderación ya que limita la posibilidad de las operaciones por lotes en el cargador. A continuación, aparece un ejemplo del uso del método Session.flush:

Session session = objectGrid.getSession();
session.begin();
// realizar algunos cambios
...
session.flush(); // pasar estos cambios al cargador, sin confirmarlos todavía
// realizar más cambios
...
session.commit();

Método NoWriteThrough

Algunas correlaciones están respaldadas por un cargador, que proporciona almacenamiento persistente para los datos de la correlación. A veces, es útil confirmar los datos sólo en la correlación de eXtreme Scale y no pasar los datos al cargador. La interfaz Session proporciona el método beginNoWriteThough con este fin. El método beginNoWriteThrough inicia una transacción como el método begin. Con el método beginNoWriteThrough, cuando se confirma la transacción , los datos solo se confirman en la correlación en memoria y no se confirman en el almacenamiento persistente proporcionado por el cargador. Este método es muy útil al realizar la precarga de datos en la correlación.

Cuando se utiliza una instancia de ObjectGrid distribuida, el método beginNoWriteThrough es muy útil para realizar cambios sólo en la memoria caché cercana, sin modificar la memoria caché lejana en el servidor. Si se sabe que los datos están obsoletos en la memoria caché cercana, el uso del método beginNoWriteThrough permite invalidar entradas en la memoria caché cercana sin invalidarlas también en el servidor.

La interfaz Session también proporciona el método isWriteThroughEnabled para determinar qué tipo de transacción está activo actualmente.

Session session = objectGrid.getSession();
session.beginNoWriteThrough();
// realizar algunos cambios ...
session.commit(); // estos cambios no se pasarán al cargador

Obtención del método del objeto TxID

El objeto TxID es un objeto opaco que identifica la transacción activa. Utilice el objeto TxID para los siguientes objetivos:

  • Para comparar cuando busque una determinada transacción.
  • Para almacenar datos compartidos entre los objetos TransactionCallback y Loader.

Consulte el plug-in TransactionCallback y los cargadores para obtener información adicional sobre la característica de ranuras de los objetos.

Método de supervisión del rendimiento

Si utiliza eXtreme Scale dentro de WebSphere Application Server, podría ser necesario restablecer el tipo de transacción para la supervisión del rendimiento. Puede establecer el tipo de transacción con el método setTransactionType. Consulte Supervisión del rendimiento de ObjectGrid con PMI (Performance Monitoring Infrastructure) de WebSphere Application Server si desea más información sobre el método setTransactionType.

Proceso de un método LogSequence completo

WebSphere eXtreme Scale puede propagar conjuntos de cambios de correlaciones a los escuchas de ObjectGrid como formas para distribuir correlaciones de una Máquina virtual Java a otra. Para facilitar al receptor el proceso de las LogSequences recibidas, la interfaz Session proporciona el método processLogSequence. Este método examina todos los LogElements de la LogSequence y realiza la operación adecuada como, por ejemplo, insert, update, invalidate, etc., en la BackingMap identificada por el MapName de LogSequence. Debe estar disponible una Session de ObjectGrid antes de que se invoque el método processLogSequence. La aplicación también es responsable de emitir las llamadas de confirmación o retrotracción adecuadas para completar la Session. El proceso de confirmación automática no está disponible para esta invocación de método. El proceso normal del ObjectGridEventListener receptor de la JVM sería iniciar una Session mediante el método beginNoWriteThrough, que evita la propagación incesante de cambios, llamar seguidamente a este método processLogSequence y, finalmente, confirmar o retrotraer la transacción.

// Utilizar el objeto Session que se ha pasado durante
//ObjectGridEventListener.initialization...
session.beginNoWriteThrough();
// procesar la LogSequence recibida
try {
	session.processLogSequence(receivedLogSequence);
}catch (Exception e) {
	session.rollback(); throw e;
}
// confirmar los cambios
session.commit();

Método markRollbackOnly

Este método se utiliza para marcar la transacción actual como "sólo de retrotracción". Marcar una transacción como "sólo de retrotracción" garantiza la retrotracción de la transacción aunque la aplicación invoque el método commit. Este método lo utiliza normalmente ObjectGrid o la aplicación cuando sabe que se pueden dañar los datos si se permite confirmar la transacción. Una vez invocado el método, el objeto Throwable que se pasa a este método se encadena a la excepción com.ibm.websphere.objectgrid.TransactionException que produce el método commit si se invoca en una sesión que se ha marcado previamente como "sólo retrotracción". Las siguientes llamadas a este método para una transacción marcada previamente como "sólo retrotracción" se ignora. Es decir, sólo se utiliza la primera llamada que pasa una referencia a Throwable no nula. Una vez finalizada la transacción marcada, se elimina la marca "sólo retrotracción" para que se pueda confirmar la siguiente transacción iniciada por la sesión.

Método isMarkedRollbackOnly

Devuelve si la sesión está marcada actualmente como "solo retrotracción". Este método devuelve boolean true si y sólo si se ha invocado previamente el método markRollbackOnly en esta sesión y la transacción iniciada por la sesión continúa activa.

Método setTransactionTimeout

Establezca el tiempo de espera de transacción para la siguiente transacción iniciada por esta sesión en un número específico de segundos. Este método no afecta al tiempo de espera de transacción de las transacciones iniciadas previamente por esta sesión. Sólo afecta a las transacciones iniciadas después de invocar este método. Si este método no se invoca nunca, se utiliza el valor de tiempo de espera que se ha pasado al método setTxTimeout del método com.ibm.websphere.objectgrid.ObjectGrid.

Método getTransactionTimeout

Este método devuelve el valor de tiempo de espera de la transacción en segundos. Este método devuelve el último valor que se ha pasado como valor de tiempo de espera al método setTransactionTimeout. Si el método setTransactionTimeout no se invoca nunca, se utiliza el valor de tiempo de espera que se ha pasado al método setTxTimeout del método com.ibm.websphere.objectgrid.ObjectGrid.

transactionTimedOut

Este método devuelve boolean true si la transacción actual iniciada por esta sesión ha excedido el tiempo de espera.

Método isFlushing

Este método devuelve un valor boolean true si y sólo si todos los cambios transaccionales se desechan en el plug-in Loader como resultado del método flush de la interfaz Session que se está invocando. Un plug-in Loader puede encontrar este método práctico si necesita saber por qué se ha invocado el método batchUpdate.

Método isCommitting

Este método devuelve boolean true si y sólo si todos los cambios de transacción se confirman como resultado del método commit de la interfaz Session que se está invocando. Este método es muy útil para los plug-ins del cargador cuando necesitan saber por qué se ha invocado el método batchUpdate.

Método setRequestRetryTimeout

Este método establece el valor de tiempo de espera de reintento de solicitud para la sesión en milisegundos. Si el cliente establece un tiempo de espera de reintento de solicitud, el valor de la sesión altera temporalmente el valor del cliente.

Método getRequestRetryTimeout

Este método obtiene el valor actual de tiempo de espera de reintento de solicitud en la sesión. Un valor de -1 indica que el tiempo de espera no se ha establecido. Un valor de 0 indica que está en la modalidad fail-fast. Un valor mayor que 0 indica el valor de tiempo de espera en milisegundos.