Hallo,
ich habe einen Web-Service (Java, Spring, JPA, Hibernate, C3P0, Oracle).

Zu Testzwecken habe ich mir einen Beispiel-Client geschrieben, der mit mehreren Threads gleichzeitig auf den Webservice zugreift, um Konflikte zu provozieren.

Wenn ich keinen Second-Level-Cache verwende, dann entstehen auch die erwarteten Optimisticlock-Exceptions (StaleObjectStateException).

Wenn ich Ehcache aktiviere, dann entstehen diese Exceptions nicht und mehrere Threads schreiben parallel auf die Datenbank und der letzte gewinnt.

Ich habe einige Entitäten mit Cache(value=true) annotiert, welche fast nie geändert werden und daher ideal für einen second level cache währen.

Auszug aus persistence.xml

<shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>

<property name="hibernate.connection.isolation" value="2"/>

<property name="hibernate.cache.use_second_level_cache" value="true"/>
<property name="hibernate.cache.use_structured_entries" value="true"/>
<property name="hibernate.cache.use_query_cache" value="true"/>
<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

ehcache.xml

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd">

<diskStore path="java.io.tmpdir/one"/>
<defaultCache

maxElementsInMemory="3000"
eternal="true"
overflowToDisk="false">
</defaultCache>

</ehcache>

Ich habe für ehcache die JMX-Überwachung aktiviert und kann sehen, daß für alle annotierten Klassen ein Cache angelegt wird und auch nur für die und dazu die zwei Standard-Caches, StandardQueryCache und UpdateTimestampsCache.

Die Klasse, für die ich Optimistick-Lock-Konflikte erwarte, ist natürlich nicht dabei.

Danke für alle Hinweise und Tips.

Ciao
Peter Schütt

Mit welcher CacheConcurrencyStrategy hast Du Deine Klassen annotiert ?
NONSTRICT_READ_WRITE, READ_WRITE, READ_ONLY oder TRANSACTIONAL ?

(Fuer Deinen konkreten Fall waeren naemlich nur erstere beide korrekt)

Mit READ_WRITE strategie solltest Du praktisch sogar jene Klasse die Du updatest fuer das 2L konfigurieren duerfen.



Was passiert mit den anderen? Bekommen die eine Exception? Welche?

Hallo,
@1
ich habe die Klassen nur mit der JPA-Annotation Cacheable annotiert.
Ich möchte auch keine hibernate-spezifischen Referenzen in die Entity-Klassen hineinziehen.
Daher weiß ich nicht, welche cache Strategie genommen wird.

@2
Eine Exception fliegt nicht.

Danke schon einmal für die schnelle Reaktion.

Ciao
Peter Schütt

@1

Laut Buch 'Java Persistence with Hibernate' muessen die Klassen mit der hibernate-spezifischen Annotation
@org.hibernate.annotations.Cache annotiert werden. (Ueber die JPA annotation @Cacheable steht absolut nichts)


Das ist schlecht. Wahrscheinlich wird dann eben ein fall-back auf eine ungeeignete Strategie passieren.



Wo ist denn das Problem damit? (Man wechselt ja schliesslich den JPA-implementor nicht alle Tage)

N.B.: Betreffende Klassen hast Du nach wie vor mit einem @Version attribute versehen, richtig?

Hallo,

[..]
>> Daher weiß ich nicht, welche cache Strategie genommen wird.

> Das ist schlecht. Wahrscheinlich wird dann eben ein fall-back auf eine ungeeignete Strategie passieren.

Kann man irgendwie feststellen, welche fall-back-Strategie er nimmt (vielleicht durch Debuggen an der richtigen Stelle)?

[..]
> Wo ist denn das Problem damit? (Man wechselt ja schliesslich den JPA-implementor nicht alle Tage)

Ich bin noch in einer recht frühen Projektphase und möchte mir noch die Option aufrechterhalten, einen anderen
JPA-Implementor zu wechseln.

> N.B.: Betreffende Klassen hast Du nach wie vor mit einem @Version attribute versehen, richtig?
Die Klassen, die nur einmal importiert werden und sich ansonsten nicht ändern, haben kein @Version-Attribut.

Alle anderen haben ein @Version-Attribut.

Ciao
Peter Schütt

Setzte jeweils einen Breakpoint auf der methode getCache in folgenden Klassen in package org.hibernate.cache:
NonstrictReadWriteCache
ReadOnlyCache
ReadWriteCache
TransactionalCache

Beim Debuggen solltest Du dann draufkommen welche fall-back-Strategie er nimmt.

Hallo,

im Constructor von SessionFactoryImpl konnte ich dort, wo die entityPersisters-Map gefüllt wird,
feststellen, daß default-mäßig der READ_WRITE-Cache verwendet wird.

Dann habe ich herausgefunden, daß man den Default-Cache mittels
<property name="hibernate.cache.default_cache_concurrency_strategy" value="READ_ONLY"/>
einstellen kann und ich habe dann READ_ONLY gewählt.

Der Fehler blieb aber.

Ich hatte übrigens ganz vergessen, zu erwähnen, welche Versionen ich verwende:
Hibernate 3.5.0-CR-2
Ehcache 2.0.0
Vielleicht kommt es auch daher, daß Ehcache in der Version noch kein Release ist, und es ist noch ein einfach ein
Fehler.
Welche Alternativen könnte man statt Ehcache nehmen?

Ciao
Peter Schütt

Hallo,

also ich persoenlich verwende Hibernate 3.5.0-CR-2 und Ehcache 1.7.1 und habe dein Problem nicht.
Ich moechte Ehcache 2.0.0 noch in dieser Woche testen, dann sage ich Dir bescheid wie es bei mir klappt...

N.B.: Verwendest Du auch die neue Konfigurations-klasse hibernate.cache.region.factory_class ?

Hallo,
ich verwende

<property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.SingletonEhCacheRegionFactory"/>

die neuen Klassen.

Ciao
Peter Schütt

Also im Buch Java Pesistence with Hibernate sind weites noch folgende cache implementationen erwaehnt:
SwarmCache, OSCache, JBossCache (jetzt Infinispan).
Achtung: JBossCache und Infinispan verlangen allerdings Integration mit JTA.

Hallo Peter,

also ich kann dein Problem nicht reproduzieren, bei mir kommt die StaleObjectStateException nach wie vor hoch:


ich benutze jetzt wie Du:


Hibernate 3.5.0-CR-2
Ehcache 2.0.0 (core distribution)


und habe einige Klassen mit Cacheable annotiert



Verwendest Du JTA oder JDBCTransactionFactory ?