Infinispan JPA Domyślny bufor cache drugiego poziomu

Question

Próbuję skonfigurować Infinispan jako hibernację cache drugiego poziomu. Wszystko jest w porządku, ale chcę poprawić domyślną konfigurację, tj. Wartości, które współdzielą wszystkie pamięci podręczne.

Buforowania są tworzone automatycznie dla podmiotów oznaczonych @Cache i można je dostosować pojedynczo w infinispan.xml przez <distributed-cache-configuratoin>. Jednak chciałbym mieć wartości domyślne (np. Strategię eksmisji) dla wszystkich tych pamięci podręcznych.

Inną kwestią jest, że chcę zaznaczyć wszystkie wygenerowane pamięci podręczne jako "rozproszone" (domyślnie są to "lokalne").

Oto exceprt z mojego infinispan.xml:

<cache-container default-cache="default" statistics="true"> 
    <transport stack="external-file" /> 
    <!-- Configuring specifics for the User entity. How to do it globally? --> 
    <distributed-cache-configuration name="user" statistics="true" /> 
</cache-container> 

Jak zrobić te rzeczy?

Answer 1

default cache configuration dla podmiotów o nazwie entity:

konfiguracja pamięci podręcznej mogą różnić się dla każdego typu danych przechowywanych w pamięci podręcznej . Aby przesłonić szablonu konfiguracji pamięci podręcznej, użyj własność hibernate.cache.infinispan.data-type.cfg gdzie data-type może być jednym z:

entity Podmiotów zaindeksowane przez @Id lub @EmbeddedId atrybutu.

immutable-entity Podmioty oznaczone adnotacją @Immutable lub jako mutable=false jako plik odwzorowania.

naturalid Podmioty indeksowane według ich atrybutu @NaturalId.

collection Wszystkie kolekcje.

timestamps Typ odwzorowania obiektu → datownik ostatniej modyfikacji. Do buforowania zapytań używany jest .

query Mapowanie zapytania → wynik zapytania.

pending-puts Pamięć podręczna pomocnicza dla regionów używających trybu unieważniania.

Domyślną collection, immutable-entity i naturalid jest również konfiguracja określona dla entity, więc nie trzeba skonfigurować je oddzielnie (jeśli nie chcesz osobne konfiguracje oczywiście), jak można zobaczyć w documentation i source code.

Uwaga

Ogólnie dokonywania cache Hibernacja L2 rozproszonej nie może być dobrym pomysłem, ponieważ instancje encji są przechowywane w disassembled hydrated state w pamięci podręcznej L2, co oznacza, że ​​tylko identyfikatory z podmiotami powiązanymi są przechowywane razem ze stanem jednostki nadrzędnej.

Załóżmy, że masz następujące podmioty (A, B, C są cachable):

@Entity 
public class A { 
    @ManyToOne 
    private B b; 

    @OneToMany 
    private Collection<C> cs; 
} 

Nawet jeśli zbiór cs były cachable również, aby w pełni zmontować jednostki A instancji z pamięci podręcznej byś następujące trasy w sieci do innych węzłów klastra:

1. Pobranie stanu podmiotu A.
2. Pobranie stanu podmiotu B na podstawie identyfikatora zapisanego w skojarzeniu b.
3. Pobierz kolekcję identyfikatorów cs.
4. Dla każdego identyfikatora w kolekcji cs należy pobrać stan jednostki C, jeden po drugim.

Oczywiście, jeśli montaż kolekcji A przypadkach (z wyniku zapytania na przykład), wszystko powyższe jest wykonywany dla każdej instancji A.

Wszystko to oznacza, że ​​odczytywanie danych bezpośrednio z bazy danych (przy prawidłowo skonfigurowanym leniwym ładowaniu, na przykład przy użyciu batch size), może być znacznie wydajniejsze niż wszystkie trasy w sieci w rozproszonej pamięci podręcznej.

Jest to również jeden z powodów, dla których pamięć podręczna encji i kolekcji powinna działać w trybie klastra unieważnień (dane są buforowane tylko w węźle, które odczytuje/zapisuje, ale są unieważniane w innych węzłach po zmianie).