Erstmal danke für Deine Antwort, leider habe ich lange keine Möglichkeit gehabt, mich noch einmal um das Problem
zu kümmern. Allerdings ist die Lösung mit einem Set für meinen Fall nicht geeignet. Vielleicht sollte ich meinen
Anwendungsfall nochmal genauer erklären.
Es gibt ein Item mit den Attributen:
Code:
id, name
Nun soll es möglich sein, Listen von diesen Items anzulegen, ähnlich bookmarks. Das Wichtige (und gleichzeitig das
Problem) ist, dass es auch möglich sein soll, Listen anzulegen, die mehrfach das gleiche Element beinhalten. Also ein
Beispiel anhand der IDs: 1, 2, 3, 1.
Also habe ich eine Klasse ItemList erstellt, welche besteht aus:
Code:
id, List<Item>, name
Durch das Hibernatemapping als m-n Beziehung entsteht eine cross-Tabelle, die das mapping übernimmt über:
Code:
listId (PK), itemId (PK), position
Rein datenbanktechnisch also kein Problem, ein m-n mapping vorzunehmen.
In meinen (vorerst fehlerhaften) unit tests ist das Problem auch nicht aufgetaucht, weil der 1st Level Cache hier
gleiche Referenzen erkennt:
Code:
Item1 item1 = new Item(...);
// zwei identische Einträge in einer Liste
myList.add(item1);
myList.add(item1);
session.saveOrUpdate(myList);
Dies legt mir tatsächlich eine Liste mit zwei identischen Einträgen an.
Der Test entspricht aber nicht meiner Situation, in der ich die Liste über RPC und somit deserialisiert bekomme.
In dem Fall hätten die beiden Einträge nicht die gleiche Referenz, sie wären nur inhaltsgleich. Dadurch geht der
1st Level-Cache von kollidieren Einträgen aus (wie Du ja bereits gesagt hast).
Mein Fehler ist also, dass ich eine Liste benutze, bei der Hibernate versucht, auch die Items selbst zu speichern,
obwohl mich nur die Einträge in der Crosstabelle (die eigentliche Liste) interessiert. Allerdings möchte ich auch einen
Listentype benutzen, bei dem automatisch die Item-Entities referenziert und mitgeladen werden, wenn ich die Liste
lade.