Java object riferimenti con strato di cache

Question

Abbiamo creato uno strato di caching al nostro J2EE-applicazione. In questo caso usiamo EHCache. Questo ha creato un paio di sfide.

Prendiamo questo esempio.

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

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

Se non siamo attenti, tutte le modifiche apportate a uno di quegli oggetti influenzeranno l'altro (che fanno riferimento allo stesso oggetto). Salvataggio OrderItem indietro al dabase renderebbe hanno lo status = 2

Come potremmo risolvere questo il modo migliore?

Abbiamo provato facendo un metodo .copyObject () per ciascun oggetto. Il che crea solo un nuovo oggetto e imposta tutti i valori. Ma questo non mi sembra una buona soluzione.

L'esempio è stato solo per illustrare. Il codice è molto più complesso di quello, ma il risultato è lo stesso.

********************** Aggiornamento 15.07.2010 ********************* *****************************

In EHCache 2 ci sono alcune opzioni per per accendere copyRead () e Copywrite (). E questo risolve tutti i miei problemi:)

Answer 1

Questo è un problema con lo stato mutevole. Non è solo la cache, è quando potresti avere più riferimenti allo stesso oggetto e l'oggetto è mutevole. Ad esempio:

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);

avrà esattamente lo stesso problema. Questo diventa ancora più complicato quando si dispone di un ambiente concorrente. Un modo per risolvere questo problema è quello di avere solo oggetti immutabili. In questo modo, se si vuole un oggetto con il diverso stato, si sta andando ad avere per fare una nuova. Inoltre rende più facile la programmazione concorrente.

Hai ragione di considerare copiare l'oggetto. Le opzioni disponibili sono:

• clonazione
• copia profonda tramite la serializzazione
• copia profonda tramite costruttori di copia

Ognuno ha i propri punti di forza e di debolezza, e che funziona meglio dipenderà dal vostro ambiente.

Answer 2

Sembra che si desidera memorizzare nella cache i dati che rappresentano un oggetto (ad esempio, i risultati di una query di database) piuttosto che un oggetto in sé (per esempio, i dati della sessione per un utente che si potrebbe voler recuperare altrove).

Se questo è il caso, il livello di cache personalizzato (circa EHCache) ha la necessità di creare un oggetto dai dati cache quando un utente effettua una richiesta - questo vi darà un oggetto unico ogni volta e non sarà possibile ottenere l'interferenza oggetto .

Answer 3

Quando si recupera dalla cache da id (getOrderItemById) Mi piacerebbe pensare che il significato di "ottenere l'oggetto in modo univoco identificato da id =?". Nel suo secondo estratto è stato (o sta cercando di avere?) 2 oggetti diversi in modo che appaia un po 'come si sta cercando di fare 2 cose contraddittorie nel codice.

Si potrebbe applicare l'univocità-Id = "ID" è sempre lo stesso oggetto. Se si imposta lo stato e quindi reimpostare esso, significa lo stesso oggetto è nuovo status. Probabilmente si ci si vuole estendere il metodo .equals che restituisca true se l'id corrisponde pure.

Si potrebbe anche usare una bandiera "sporco" per contrassegnare gli oggetti che sono stati cambiati dalla (transazionale?) Archivio dati.

Esecuzione di una copia non è un brutto modo di affrontare questo sia, anche se non è chiaro che cosa significa avere 2 oggetti in giro con lo stesso ID. Forse la copia deve essere creato con un id null per indicare che non esiste nella cache ancora?

Qual è il comportamento giusto per la vostra applicazione?

Answer 4

EHCache fornire supporto per bloccare chiavi tramite API blocco esplicito. È possibile bloccare sulla chiave nella cache di lettura e scrittura con le serrature. Questo non blocca sul valore nella cache, in modo da l'oggetto è ancora aperto ad una mutazione se il programmatore decide in tal senso.

Questo può o non può risolvere il problema si parla, a seconda di come lo si vede. Se il programmatore è hanno voglia di essere disciplinato, e usa gli oggetti di lettura acquisita solo per scopi di lettura, e modificare + cache di aggiornamento al momento dell'acquisto di oggetti con blocco di scrittura sulla chiave, quindi questo dovrebbe funzionare.

Tuttavia, il problema stato mutevole, come cita Jamie McCrindle, non se ne va.

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