Java referencias a objetos con capa de caché

Question

Hemos creado una capa de almacenamiento en caché en nuestro J2EE-aplicación. En este caso utilizamos Ehcache. Esto ha creado algunos desafíos.

Vamos a tomar este ejemplo.

OrderItem orderitem = cache.getOrderItemByID("id");
OrderItem old_orderitem = cache.getOrderItemID("id");

orderitem.setStatus(1);
old_orderitem.setStatus(2);

Si no estamos cuidado, cualquier cambio realizado en cualquiera de esos objetos afecta a la otra (que hacen referencia al mismo objeto). El ahorro de pedido de nuevo a la dabase sería hacer que tenga el estado = 2

¿Cómo podemos resolver este la mejor manera?

Hemos intentado hacer un método .copyObject () para cada objeto. Lo cual crea un nuevo objeto y establece todos los valores. Pero esto no parece ser una buena solución.

El ejemplo era simplemente para ilustrar. El código es mucho más compleja que eso, pero el resultado es el mismo.

********************** actualización 15.07.2010 ********************* *****************************

En EHCache 2 hay algunas opciones para dar vuelta en copyRead () y de derecho de autor (). Y esto resuelve todos mis problemas:)

Answer 1

Este es un problema con el estado mutable. No sólo es el almacenamiento en caché, es cualquier momento se pueden tener varias referencias al mismo objeto y ese objeto es mutable. Por ejemplo:

HashMap map = new HashMap();
map.put("one", new OrderItem());
OrderItem one = map.get("one");
OrderItem two = map.get("one");
one.setStatus(1);
two.setStatus(2);

tendrá exactamente el mismo problema. Esto se complica aún más cuando se tiene un entorno concurrente. Una manera de resolver esto es sólo para que los objetos inmutables. De esa manera, si quieres un objeto con diferente estado, vas a tener que hacer una nueva. También hace más fácil la programación concurrente.

Tienes razón para considerar la copia del objeto. Las opciones son:

• Clonación
• copia profunda a través de la serialización
• copia profunda a través de constructores de copia

Cada uno tiene sus fortalezas y debilidades y cuál funciona mejor dependerá de su medio ambiente.

Answer 2

Parece que usted quiere almacenar los datos que representan un objeto (por ejemplo, los resultados de una consulta de base de datos) en lugar de un objeto en sí (por ejemplo, datos de sesión de un usuario que es posible que desee recuperar en otro lugar).

Si este es el caso, la capa de Cacheing personalizado (alrededor ehcache) tiene que crear un objeto a partir de los datos de la memoria caché cuando un usuario hace una petición - esto le dará un objeto único en todo momento y no obtendrá la interferencia de objetos .

Answer 3

Cuando se recupera de la memoria caché por id (getOrderItemById) Me asumir que eso significa "obtener el objeto únicamente identificada por id =?". En el segundo fragmento que haya (o está tratando de tener?) 2 objetos diferentes para que se vea un poco como que está tratando de hacer 2 cosas contradictorias en el código.

Se podría exigir la unicidad-id = "ID" es siempre el mismo objeto. Si establece el estado y se vuelve a establecer, esto significa que el mismo objeto tiene nuevo estado. Probablemente usted desea extender el método para volver .equals cierto si el id también coincide.

También es posible usar un indicador "sucio" para señalar objetos que han cambiado desde la (transaccional?) De almacenamiento de datos.

Para hacer una copia no es una mala manera de hacer frente a este tampoco, aunque no está claro lo que significa tener 2 objetos corriendo con el mismo ID. Tal vez la copia debe ser creado con identidad nulo para indicar que no existe en la memoria caché todavía?

¿Cuál es el comportamiento adecuado para su aplicación?

Answer 4

Ehcache proporcionar soporte para el bloqueo de teclas a través de una API de bloqueo explícita. Puede bloquear la tecla en la memoria caché de lectura y escritura con cerraduras. Esto no se bloquea en el valor en la memoria caché, por lo que el objeto aún está abierta a la mutación si el programador así lo decide.

Esto puede o no puede resolver el problema que mencionas, dependiendo de cómo lo veas. Si el programador es ¡dispuestos a ser disciplinado, y utiliza los objetos de lectura adquiridos sólo para propósitos de lectura, y modificar + caché de actualización cuando se adquieren objetos con bloqueo de escritura en la tecla, entonces esto debería funcionar.

Sin embargo, el problema de estado mutable, como se menciona Jamie McCrindle, no desaparece.

Referencia: http://ehcache.org/documentation/explicitlocking.html