La interfaz ObjectMap se utiliza para la interacción transaccional entre aplicaciones
y BackingMaps.
Finalidad
Una instancia de ObjectMap se obtiene de un objeto Session que se corresponde con la hebra actual. La interfaz ObjectMap es el vehículo principal que utilizan las aplicaciones para realizar cambios en las entradas de una BackingMap.
Obtener una instancia de ObjectMap
Una aplicación obtiene una instancia de ObjectMap de un objeto Session mediante el método
Session.getMap(String).
El siguiente fragmento de código demuestra cómo se obtiene una instancia de ObjectMap:
ObjectGrid objectGrid = ...;
BackingMap backingMap = objectGrid.defineMap("mapA");
Session sess = objectGrid.getSession();
ObjectMap objectMap = sess.getMap("mapA");
Cada instancia de ObjectMap se corresponde con un determinado objeto Session. Al llamar varias veces al método
getMap en un determinado objeto Session con el mismo nombre BackingMap, siempre se devuelve la misma instancia de ObjectMap.
Confirmar automáticamente transacciones
Las operaciones realizadas en
BackingMaps que utilizan ObjectMaps y JavaMaps se realizan con mayor eficacia dentro de una transacción de Session. WebSphere eXtreme
Scale proporciona el soporte de confirmación automática cuando se llama a los métodos de las interfaces ObjectMap y JavaMap fuera de una transacción de Session. Los métodos inician una transacción implícita, realizan la operación solicitada y confirman la transacción implícita.
Semántica de los métodos
A continuación se proporciona una explicación de la semántica en la que se basan todos los métodos de las interfaces ObjectMap y JavaMap.
- Método containsKey
- El método containsKey determina si una clave tiene un valor en
BackingMap o Loader. Si una aplicación da soporte a valores nulos, este método puede utilizarse para determinar si una referencia nula devuelta por una operación get hace referencia a un valor nulo o indica que la BackingMap y el Loader no contienen la clave.
- Método flush
- La semántica del método flush es parecida al método flush en la interfaz Session. La diferencia importante es que el desecho de Session se aplica a los cambios pendientes actuales de todas las correlaciones que se han modificado en la sesión actual. Con este método, sólo los cambios de esta instancia de ObjectMap se desechan en el Loader.
- Método get
- El método get capta la entrada de la instancia de BackingMap.
Si la entrada no se encuentra en la instancia de BackingMap pero existe un
Loader asociado a la instancia de BackingMap, la instancia de BackingMap intenta captar la entrada del Loader. El método getAll se proporciona para permitir el proceso de captación de lotes.
- Método getForUpdate
- El método getForUpdate es igual al método get, aunque si se utiliza el método getForUpdate se indica a la BackingMap y al Loader que la intención es actualizar la entrada. Un Loader puede utilizar esta sugerencia para emitir un consulta SELECT for UPDATE a un programa de fondo de base de datos.
Si se define una LockingStrategy pesimista para la BackingMap, el gestor de bloqueos bloquea la entrada. El método getAllForUpdate se proporciona para permitir el proceso de captación de lotes.
- Método insert
- El método insert inserta una entrada en la
BackingMap y el Loader. Si se utiliza este método se indica a la BackingMap
y al Loader que desea insertar una entrada que no existía previamente.
Al invocar este método en una entrada existente, se genera una excepción cuando se invoca el método o se confirma la transacción actual.
- Método invalidate
- La semántica del método invalidate depende del valor del parámetro
isGlobal que se pase al método. El método invalidateAll se proporciona para permitir el proceso de anulación de lotes.
La anulación local se especifica cuando se pasa el valor false como parámetro isGlobal del método de anulación. La anulación local descarta todos los cambios realizados en la entrada en la memoria caché de transacción. Si la aplicación emite un método get, la entrada se capta del último valor confirmado en la BackingMap.
Si no existe ninguna entrada en la BackingMap, la entrada se capta del último valor confirmado o desechado del Loader. Cuando se confirma una transacción, todas las entradas que se han marcado como anuladas localmente no tienen ningún impacto en la BackingMap. Todos los cambios que se hayan desechado al Loader siguen estando comprometidos incluso si se ha desechado la entrada.
La anulación global se especifica cuando se pasa true como parámetro isGlobal del método invalidate. La anulación global descarta cualquier cambio pendiente de la entrada de la memoria caché de transacciones y omite el valor de BackingMap en operaciones posteriores que se realicen en la entrada. Cuando se confirma una transacción, todas las entradas que se han marcado como anuladas globalmente se desalojan de la BackingMap.
Considere el siguiente caso de uso de anulación como ejemplo: la BackingMap está respaldada por una base de datos que tiene una columna de incremento automático. Las columnas de incremento son útiles para asignar números exclusivos a los registros. La aplicación inserta una entrada. Después de la inserción, la aplicación necesita saber el número de secuencia de la fila insertada. Sabe que su copia del objeto es antigua, así que utiliza la anulación global para obtener el valor del Loader.
El siguiente código demuestra este caso de uso:Session sess = objectGrid.getSession();
ObjectMap map = sess.getMap("mymap");
sess.begin();
map.insert("Billy", new Person("Joe", "Bloggs", "Manhattan"));
sess.flush();
map.invalidate("Billy", true);
Person p = map.get("Billy");
System.out.println("Version column is: " + p.getVersion());
map.commit();// Cierre la sesión (opcional en la versión 7.1.1 y posterior) para un mejor rendimiento
session.close();
Este ejemplo de código añade una entrada para
Billy. El atributo de versión de Person se establece mediante una columna de incremento automático de la base de datos. La aplicación realiza primero un mandato de inserción. Después emite un desecho, que hace que la inserción se envíe al Loader y a la base de datos. La base de datos establece la columna de versión en el siguiente número de la secuencia, lo que provoca que el objeto Person quede obsoleto. Para actualizar el objeto, la aplicación se anula globalmente. El siguiente método get que se emite obtiene la entrada del
Loader, e ignora el valor de transacción. La entrada se capta de la base de datos con el valor de versión actualizado.
- Método put
- La semántica del método put depende de si se ha invocado previamente un método get en la transacción para la clave.
Si la aplicación emite una operación get que devuelve una entrada existente de la BackingMap o el Loader, la invocación del método put se interpreta como una actualización y devuelve el valor anterior en la transacción. Si se ha ejecutado la invocación a un método put sin una invocación al método get anterior, o una invocación al método get anterior no ha encontrado una entrada, la operación se interpreta como una inserción. La semántica de los métodos
insert y update se aplica cuando se confirma la operación
put. El método putAll se proporciona para habilitar el proceso de actualización e inserción de lotes.
- Método remove
- El método remove elimina la entrada de
BackingMap y el cargador, si hay un cargador conectado. Este método devuelve el valor del objeto que se eliminó. Si el objeto no existe, este método devuelve un valor nulo.
El método removeAll se proporciona para habilitar el proceso de supresión de lotes sin los valores de retorno.
- Método setCopyMode
- El método setCopyMode especifica un valor CopyMode
para esta ObjectMap. Con este método, una aplicación puede alterar temporalmente el valor CopyMode que se especifica en la BackingMap. El valor CopyMode especificado está en vigor hasta que se invoca el método clearCopyMode. Ambos métodos se invocan fuera de los límites transaccionales. Un valor CopyMode no puede cambiarse en la mitad de una transacción.
- Método touch
- El método touch actualiza la hora del último acceso para una entrada.
Este método no recupera el valor de la BackingMap. Utilice este método en su propia transacción.
Si la clave proporcionada no existe en la BackingMap debido a la anulación o eliminación, se produce una excepción durante el proceso de confirmación.
- Método update
- El método update actualiza de forma explícita una entrada en la
BackingMap y el Loader. Si se utiliza este método se indica a la
BackingMap y al Loader que desea actualizar una entrada existente. Si se invoca este método en una entrada que no existe cuando se invoca el método o durante el proceso de confirmación, se producirá una excepción.
- Método getIndex
- El método getIndex intenta obtener un índice con nombre que se basa en la
BackingMap. El índice no se puede compartir entre hebras y se ocupa de las mismas reglas que una
Session. El objeto de índice devuelto se debe convertir a la interfaz de índice de aplicación correcta como, por ejemplo, la interfaz MapIndex, la interfaz MapRangeIndex o una interfaz de índice personalizada.
- Método clear
- El método clear elimina todas las entradas de la memoria caché de una correlación desde todas las particiones. Esta operación es una función de confirmación automática, por ello no debe haber ninguna transacción activa cuando se invoca el método clear.
Nota: el método clear sólo borra la correlación en la que se llama, y las correlaciones de entidad relacionadas no se ven afectadas. Este método no invoca el plug-in Loader.