Ich versuche, ein Objekt im Hibernate-Cache der zweiten Ebene zwischenzuspeichern, das eine Verbund-ID in meiner Persistenz-Mapping-Datei zugeordnet hat. Die Protokolle sagen, dass beim ersten Ausführen der Abfrage die als Composite-ID zugeordnete Klasse in den Cache gestellt wird. Wenn ich die Abfrage ein zweites Mal ausführen, wird das Objekt jedoch nicht aus dem Cache abgerufen. Stattdessen wird die Abfrage erneut ausgeführt.
Hat Hibernate ein Problem mit der Zwischenspeicherung von zusammengesetzten IDs auf der zweiten Ebene?
Relevante Informationen:
So erstelle ich meine ID und führe meine Abfrage aus:
%Vor%Und so definiert meine Persistenz-Mapping-Datei das obige:
%Vor%EDIT: Die Handlung verdichtet sich ....
Als ich dies in eine schreibgeschützte Cache-Richtlinie änderte, funktionierte es einwandfrei. Das Transaktions-Cache-Verhalten scheint extrem unberechenbar zu sein. Kann jemand erklären, warum das oben erwähnte mit einem Lese- / Schreibcache geschah, aber mit Read-only gut funktionierte? Diese Tabelle wird nicht aktualisiert, daher ist nicht sicher, warum transaktionale Semantiken die Dinge in dieser Instanz ändern würden.
Das sieht aus wie ein gemeldeter Fehler mit Hibernate . Scheint, dass Sie als Workaround können in der Lage sein, erfolgreich den Cache zu treffen, wenn Sie dieselbe Instanz Ihres zusammengesetzten Schlüssels verwenden, im Gegensatz zu einem, der .equals() ist.
Es gibt auch einen Patch auf dem Fehlerbericht, Sie könnten ihn vielleicht selbst anwenden und Ihren eigenen gepatchten Hibernate Build erstellen.
Tags und Links hibernate second-level-cache ehcache composite-primary-key