Acceso a datos y transacciones

Una vez que una aplicación tenga una referencia a una instancia de ObjectGrid o a una conexión de cliente con una cuadrícula de datos remota, podrá acceder a datos de la cuadrícula e interactuar con ellos. Con la API de ObjectGridManager, puede crear una instancia local o establecer una conexión de cliente con una instancia distribuida. Para crear una instancia local, utilice uno de los métodos createObjectGrid. Para establecer una conexión de cliente con una cuadrícula de datos remota, utilice el método getObjectGrid.

Una hebra en una aplicación necesita su propia sesión (Session). Si desea que la aplicación utilice el ObjectGrid en una hebra, llame a uno de los métodos getSession para obtener una sesión. Una vez que la aplicación haya terminado con la sesión, llame al método Session.close(). Este método cierra la sesión, la devuelve a la agrupación y libera sus recursos. El cierre de una sesión es opcional, pero mejora el rendimiento de las llamadas posteriores al método getSession(). Si la aplicación utiliza una infraestructura de inyección de dependencia como, por ejemplo Spring, puede inyectar una Session en un bean de aplicación, cuando sea necesario.

Después de obtener una Sesión, la aplicación puede acceder a los datos almacenados en correlaciones en el ObjectGrid. Si el ObjectGrid utiliza entidades, puede utilizar la API EntityManager, que puede obtener con el método Session.getEntityManager. Puesto que es cercano a las especificaciones Java, la interfaz EntityManager es más sencilla que la API basada en correlación. Sin embargo, la API EntityManager conlleva una sobrecarga de rendimiento porque rastrea los cambios en los objetos. La API basada en correlación se obtiene a través del uso del método Session.getMap.

WebSphere eXtreme Scale utiliza transacciones. Cuando una aplicación interactúa con un elemento Session, debe ser en el contexto de una transacción. Una transacción se inicia y confirma o se retrotrae utilizando los métodos Session.begin, Session.commit y Session.rollback en el objeto Session. Las aplicaciones también pueden funcionar en modalidad de confirmación automática, según la cual el elemento Session se inicia automáticamente y confirma una transacción siempre que la aplicación interactúa con correlaciones. Sin embargo, la modalidad de confirmación automática es más lenta.

La lógica del uso de transacciones

Las transacciones pueden parecer lentas. Debe utilizar las transacciones por las siguientes razones:
  1. Para permitir la retrotracción de cambios si se produce una excepción o si la lógica empresarial necesita deshacer cambios de estado.
  2. Para mantener bloqueos en datos y liberar bloqueos dentro del ciclo de vida de una transacción, lo que permite que se realicen automáticamente un conjunto de cambios, es decir, o todos los cambios o ningún cambio.
  3. Para producir una unidad atómica de réplica.

Puede personalizar cuánto soporte se necesita para las transacciones. Su aplicación puede desactivar el soporte de retrotracción y el bloqueo, pero ello conlleva un coste para la aplicación. La aplicación deberá manejar la falta de estas características.

Por ejemplo, una aplicación puede desactivar el bloqueo mediante el establecimiento del valor NONE en la estrategia de bloqueo de BackingMap. Esta estrategia es rápida, pero las transacciones simultáneas ahora pueden modificar los mismos datos sin protección entre ellas. La aplicación es responsable de la coherencia de los datos y el bloqueo cuando se utiliza NONE.

Una aplicación también puede cambiar la forma en que se copian los objetos cuando la transacción accede a éstos. La aplicación puede especificar cómo se copian los objetos con el método ObjectMap.setCopyMode. Con este método, puede desactivar CopyMode. Normalmente, la modalidad CopyMode desconectada se utiliza para las transacciones de sólo lectura, si se pueden devolver distintos valores para el mismo objeto dentro de una transacción. Se pueden devolver distintos valores para el mismo objeto dentro de una transacción.

Por ejemplo, si la transacción ha llamado al método ObjectMap.get para el objeto en T1, obtuvo el valor en ese momento puntual. Si vuelve a llamar al método get dentro de dicha transacción en otro momento posterior T2, otra hebra podría haber cambiado el valor. Puesto que el valor ha sido modificado por otra hebra, la aplicación ve un valor distinto. Si la aplicación modifica un objeto recuperado utilizando un valor NONE de CopyMode, está cambiando la copia confirmada de dicho objeto directamente. Retrotraer la transacción no tiene sentido en esta modalidad. Modifica la única copia de ObjectGrid. Aunque utilizar NONE CopyMode es rápido, debe ser consciente de sus consecuencias. Una aplicación que utiliza NONE CopyMode nunca debe retrotraer la transacción. Si la aplicación retrotrae la transacción, los índices no se actualizan con los cambios y los cambios no se duplican, si la réplica está activa. Los valores predeterminados son fáciles de utilizar y menos propensos a errores. Si inicia el rendimiento en favor de unos datos menos fiables, la aplicación necesita saber qué está haciendo para evitar problemas no deseados.

PRECAUCIÓN:
Extreme las precauciones cuando modifique el bloqueo o los valores CopyMode. Si cambia los valores, se produce un comportamiento impredecible de la aplicación.

Interacción con los datos almacenados

Después de obtener una sesión, puede utilizar el siguiente fragmento de código para utilizar la API de correlación para insertar datos.

Session session = ...;
ObjectMap personMap = session.getMap("PERSON");
session.begin();
Person p = new Person();
p.name = "John Doe";
personMap.insert(p.name, p);
session.commit();

El mismo ejemplo que utiliza la API EntityManager es el siguiente. Este código de ejemplo da por supuesto que el objeto Person está correlacionado con una entidad.

Session session = ...;
EntityManager em = session.getEntityManager();
session.begin();
Person p = new Person();
p.name = "John Doe";
em.persist(p);
session.commit();

El patrón se ha diseñado para obtener referencias a ObjectMaps para las correlaciones con las que trabaja la hebra, iniciar una transacción, trabajar con los datos y, después, confirmar la transacción.

La interfaz ObjectMap incluye las operaciones de correlación típicas, como put, get y remove. Sin embargo, utilice nombres de operación más específicos como: get, getForUpdate, insert, update y remove. Estos nombres de método expresan la intención de forma más precisa que las API de correlación tradicionales.

También puede utilizar el soporte de indexación, que es flexible.

A continuación, aparece un ejemplo para actualizar un objeto:

session.begin();
Person p = (Person)personMap.getForUpdate("John Doe");
p.name = "John Doe";
p.age = 30;
personMap.update(p.name, p);
session.commit();

Normalmente, la aplicación utiliza el método getForUpdate en lugar de un sencillo método get para bloquear el registro. El método update debe llamarse para proporcionar el valor actualizado a la correlación. Si no se llama este método, la correlación no se modificará. A continuación, aparece el mismo fragmento utilizando la API EntityManager:

session.begin();
Person p = (Person)em.findForUpdate(Person.class, "John Doe");
p.age = 30;
session.commit();

La API EntityManager API es más sencilla que el enfoque de correlación. En este caso, eXtreme Scale encuentra la entidad y devuelve un objeto gestionado a la aplicación. La aplicación modifica el objeto y confirma la transacción, y eXtreme Scale rastrea los cambios en los objetos gestionados de forma automática durante la confirmación y realiza las actualizaciones necesarias.

Transacciones y particiones

Las transacciones de WebSphere eXtreme Scale pueden actualizar una única partición. Las transacciones de un cliente pueden leer de varias particiones, pero sólo pueden actualizar una partición. Si una aplicación intenta actualizar dos particiones, la transacción falla y se retrotrae. Una transacción que utiliza un ObjectGrid incorporado (lógica de cuadrícula) no tiene capacidad de direccionamiento y sólo puede ver los datos de la partición local. Esta lógica empresarial siempre puede obtener una segunda sesión que sea una verdadera sesión de cliente para acceder a otras particiones. Sin embargo, esta transacción debería ser una transacción independiente.

Consultas y particiones

Si una transacción ya ha buscado una entidad, la transacción se asocia a la partición de dicha entidad. Cualquier consulta que se ejecute en una transacción asociada a una entidad se direcciona a la partición asociada.

Si una consulta se ejecuta en una transacción antes de que se asocie a una partición, debe establecer el ID de partición para utilizar para la consulta. El ID de partición es un valor entero. La consulta se direcciona entonces a dicha partición.

Las consultas sólo buscan dentro de una única partición. Sin embargo, puede utilizar las API DataGrid para ejecutar la misma consulta en paralelo en todas las particiones o un subconjunto de particiones. Utilice las API DataGrid para encontrar una entrada que pudiera estar en una partición.

El servicio de datos REST permite a cualquier cliente HTTP acceder a una cuadrícula de WebSphere eXtreme Scale y es compatible con WCF Data Services en Microsoft .NET Framework 3.5 SP1. Para obtener más información, consulte Configuración de servicios de datos REST.

.