Beziehungen, die für zugeordnete Objekte in der Hibernate + Gilead-Anwendung gelöscht werden

Question

Bearbeiten 5/11/2011:

Ich denke, es ist ein bisschen schlimmer als das, was unten steht. Wenn ich in meiner bereitgestellten QS-Instanz das Haupt-Dashboard nur mehrmals aktualisiere, werden schließlich die vielen-zu-vielen Gruppenzuordnungen meines Benutzers gelöscht. Zu diesem Zeitpunkt werden nur ausgewählte Anweisungen auf der Serverseite aufgerufen. hoffentlich werde ich es mit diesen neuesten Tests eingrenzen.

Original:

Hallo zusammen. Ich habe ein Problem mit einem ziemlich komplexen Objekt. Das Problem ist wie folgt: Wenn ich das Objekt vom Client zum Server sende, um es zu speichern, werden scheinbar viele-zu-viele-Beziehungen zu zugeordneten Objekten zufällig gelöscht. Schlimmer noch, ich bin nicht in der Lage, das Problem selbst zu reproduzieren, nachdem ich ungefähr zwei Monate lang das Problem erkannt habe. Ich habe die App zum Testen mit einer QS-Gruppe herausgebracht. Sie verwenden das Programm täglich und geben die neuen und älteren Anwendungen doppelt ein. Das Problem tritt bis zu dreimal am Tag auf.

Ich werde mein Bestes tun, um so viele Details wie möglich bereitzustellen, und ich schätze es sehr, wenn jemand einen Blick darauf wirft!

Das App-Framework ist GWT 2.1 + Gilead + Hibernate 3 + MySQL InnoDB. Ich lasse Hibernate alle Kaskadierungen usw. verarbeiten, sodass in der Datenbank keine definiert ist, obwohl alle Fremdschlüssel in der Datenbank festgelegt sind.

Hier einige Auszüge aus den Zuordnungen:

<hibernate-mapping>
 <class name="com.example.domain.Close" table="CLOSE">

 <many-to-one name="updateUser"
class="com.example.domain.User"
column="LAST_UPDATE_USER"/>
 </class>
</hibernate-mapping>

<hibernate-mapping>
  <class name="com.example.domain.User" table="USER" batch-size="25">
    <set name="groups" table="USER_GROUP" lazy="true" batch-size="25">
      <key column="USER_ID"/>
      <many-to-many column="GROUP_ID" class="com.example.domain.Group"/>
    </set>
  </class>
</hibernate-mapping>

<hibernate-mapping>
  <class name="com.example.domain.Group" 
    table="GROUP" batch-size="25">
    <set name="users" table="USER_GROUP" lazy="true" inverse="true">
      <key column="GROUP_ID"/>
      <many-to-many column="USER_ID" class="com.example.domain.User"/>
    </set>
    <set name="permissions" table="PERMISSION_GROUP" lazy="true" inverse="true">
    <key column="GROUP_ID"/>
    <many-to-many column="PERMISSION_ID" 
      class="com.example.domain.Permission"/>
    </set>

<hibernate-mapping>
  <class name="com.example.domain.Permission" 
      table="PERMISSION">
    <set name="groups" table="PERMISSION_GROUP" lazy="true">
      <key column="PERMISSION_ID"/>
      <many-to-many column="GROUP_ID" 
        class="com.example.domain.Group"/>
    </set>
  </class>
</hibernate-mapping>

Das Speichern des Objekts ist einfach ein Aufruf von saveOrUpdate ():

Session session = gileadHibernateUtil.getSessionFactory()
  .getCurrentSession();
session.beginTransaction();
try {
  session.saveOrUpdate(close);
} catch (Exception e) {
  e.printStackTrace();
  session.getTransaction.rollback();
}
session.getTransaction.commit();

return close;

Der Close 'updateUser' ist ein Objekt, das beim Anmelden des Benutzers geladen wird. Er wird mit den zugehörigen Gruppen und Berechtigungen geladen, damit das System den Zugriff auf App-Module gewähren / verweigern kann. Ich mache

close.setUpdateUser(exampleApp.getUser()); 

bevor Sie das Objekt an den Server zurücksenden.

Es gibt viele andere Stellen in der App, an denen diese Art von Operation stattfindet, die jedoch keine unerwünschten Nebenwirkungen verursachen. Dies hängt wahrscheinlich mit der Komplexität des clientseitigen Codes zusammen, der dem Close-Objekt zugeordnet ist, oder vielmehr mit meiner Implementierung.

Ich habe so viel Zeit damit verbracht, die offiziellen Hibernate-Dokumente zu durchsuchen, nach möglichen Problemen zu suchen usw. Ich dachte, es wäre ein guter Zeitpunkt, um um Hilfe zu bitten. Ich muss mich bemannen und dranbleiben, aber vielleicht hilft mir nur das Fragen, es herauszufinden.

Ich bin mir nicht sicher, was ich im Moment noch anbieten soll, was relevant ist. Hoffentlich hat das, was bisher hier ist, Relevanz!

Danke fürs Zuhören!

Bearbeiten

May  5 12:18:38 localhost jsvc.exec[10117]: Hibernate: insert into example_dev.RECENT_ITEM (OBJECT_TYPE, OBJECT_ID, DATE, USER_ID) values (?, ?, ?, ?)
May  5 12:18:38 localhost jsvc.exec[10117]: Hibernate: delete from example_dev.PERMISSION_GROUP where PERMISSION_ID=?
May  5 12:18:38 localhost last message repeated 19 times
May  5 12:18:38 localhost jsvc.exec[10117]: Hibernate: delete from example_dev.USER_GROUP where USER_ID=?
May  5 12:18:38 localhost jsvc.exec[10117]: Hibernate: delete from example_dev.USER_DESIGNATION where USER_ID=?

Es scheint, dass Löschvorgänge direkt nach dieser Einfügung stattfinden. Vorherige Vorgänge werden alle ausgewählt. Es sollte jedoch nichts in User von RecentItem kaskadiert werden.

Answer 1

Nach vielen Recherchen bin ich zu einigen Schlussfolgerungen gekommen und konnte Maßnahmen ergreifen. Zunächst habe ich nach langem Suchen im Gilead-Forum erfahren, dass es sich nicht mehr um aktiv gepflegt . Hätte das früher bemerken sollen. In der Zwischenzeit hatte ich angefangen, über RequestFactory zu lesen, und nach ein paar Tagen Recherche entschied ich, dass ich versuchen sollte, darauf zu migrieren.

Dies ist ein ziemlich großes Projekt, ungefähr 50 Domänenobjekte, einige mit vielen Objektassoziationen. Ich habe ungefähr 40-50 Stunden gebraucht, um alles neu zu schreiben, von der Verwendung von Gilead + GWT RPC bis zur ausschließlichen Verwendung von RequestFactory. Ich bin ziemlich zufrieden mit den daraus resultierenden Änderungen in Code und Struktur. Bisher hat es mich nicht allzu sehr gestört, DTO-Proxy-Objekte erstellen zu müssen, und ich habe die Gelegenheit genutzt, zu Annotationen im Ruhezustand zu wechseln und die Zuordnungsdateien zu entfernen.

Es war manchmal schwierig, den Code zu überarbeiten, um die für RequestFactory erforderlichen Abruf-, Bearbeitungs- und Speicherzyklen zu verwenden. Es gab mir die Möglichkeit, einen Teil des Codes zu verbessern.

Die gute Nachricht ist, dass das Problem behoben wurde. Keine viele-zu-viele-Assoziationen mehr, die auf mysteriöse Weise gelöscht werden. Ich gehe davon aus, dass ich in Gilead einen Fehler gefunden habe oder dass meine Verwendung falsch war oder dass ich möglicherweise ein Problem bei der Migration zu Annotations behoben habe.

Beim Erlernen von RequestFactory + Hibernate bin ich auf einige großartige Ressourcen gestoßen, viele davon über StackOverflow (nochmals vielen Dank!):

Verwenden von GWT RequestFactory mit Objectify - war großartig, um ein Gefühl dafür zu bekommen, wie RequestFactory mit dem Backend interagierte, und einige Methoden und Boilerplates, um Code zu reduzieren.

Weitere Links hoffentlich unten. Ich bin immer noch ein Neuling, daher bin ich in der Anzahl der Hyperlinks, die ich posten kann, begrenzt :)

Ich habe viel gelernt und spreche fließend RequestFactory. Ich werde mein Bestes tun, um ein Auge auf mich zu werfen und hier zu helfen, wo ich denke, dass ich kann.

Danke StackOverflow!