Mi sto interrogando sul seguente scenario: è nella terra di Spring / AOP e Ehcache.
Accade nell'applicazione Web REST - REST / Service / DAO layers - Ho degli oggetti nella cache ( @Repository
+ @Cacheable
). Su particolare richiesta di REST (chiamiamola /notUpdateRelated
), dopo che la richiesta è stata completata con successo (in questo caso è sufficiente non lanciare un'eccezione), devo aggiornare la cache.
Le chiamate sull'endpoint /notUpdateRelated
possono verificarsi da thread diversi.
Quindi ho cercato un paio di opzioni:
- L'approccio diretto sarebbe quello di esporre il metodo di rimozione della cache sicuro dal thread e modificare il codice del servizio
/notUpdateRelated
. In questo modo, prima che il controller ritorni dall'esecuzione della richiesta/notUpdateRelated
, posso attivare lo sfratto della cache.
Ciò che non mi piace di questo approccio è che, come avrete intuito, non è responsabilità del servizio /notUpdateRelated
rimuovere la cache. Purtroppo lo sgombero della cache è richiesto solo per questa chiamata di servizio e non è possibile che altri servizi lo facciano.
- Posso usare l'annotazione
@After
dell'AOP (dopo aver restituito il consiglio) e fare lo stesso come sopra. In questo modo la modifica del servizio/notUpdateRelated
sarà minima.
Ciò che non mi piace di questo approccio è che questa non è una vera preoccupazione trasversale per le classi di applicazioni.
-
Posso usare
Interceptor
/Filter
sulla risposta di/notUpdateRelated
e attivare l'eliminazione della cache lì, ma questo sembra un uso improprio degli oggetti di cui sopra.Ci sono possibili approcci con cui non ho familiarità. Sarò felice di considerare qualsiasi cosa migliore. Quale pensi sia l'approccio migliore in questa situazione?