Java, Hibernate: Persistieren eines Objektes in Oracle-DB

[barnti]

Hallo Gemeinde,

ich habe ein Problem beim Persistieren eines Java-Objektes mittels Hibernate in einer Oracle-DB. Das Persistieren wird im Code ausgeführt:

Delphi-Quellcode:

public void persist(Rqs transientInstance) {
      log.debug("persisting Rqs instance");
      Transaction tx = null;
      try {
         tx = getCurrentSession().beginTransaction();
         getCurrentSession().save(transientInstance);//persist(transientInstance);
         if (!tx.wasCommitted()) 
            tx.commit();
         log.debug("persist successful");
      } catch (RuntimeException re) {
         log.error("persist failed", re);
         if(tx != null)
            tx.rollback();
         throw re;
      }
      finally{
         getCurrentSession().close();
      }
   }

Die Debug-Console zeigt mir keine Exceptions oder sonstige Hinweise auf Probleme. In der Datenbank ist anschließend kein neuer Eintrag zu finden...

Kann jemand damit etwas anfangen? Ich brauche einen Denkanstoß oder eine Vorgehensweise wie ich den Fehler lokalisieren kann? Wer verpasst mir einen Klapps auf den Hinterkopf?

[Chewie]

Also ich benutz immer Code, der etwa so aussieht:

Code:

Session session = HibernateSessionFactory.currentSession();
Transaction tx = null;
try {
   tx = session.beginTransaction();
   session.save(transientObject);  //oder halt update()/persist() etc.
   tx.commit();
   if (log.isDebugEnabled()) {
      log.debug("Objekt gespeichert.");
   }
} catch (HibernateException e) {
   if (log.isErrorEnabled()) {
      log.error("Fehler beim Modifizieren des Objekts.", e);
   }
   
   if (tx != null)
      tx.rollback();
   return false;
} finally {
   HibernateSessionFactory.closeSession();
}

Also im Wesentlichen der gleiche Code wie du. Das hat auch mit ner Oracle-Datenbank funktioniert.

[Der_Unwissende]

Hi,
ich kann dir zwar nicht direkt einen Tipp geben, aber bist du mal im Einzelschrittmodus durchgelaufen? Ich hab ein wenig die Vermutung, dass dein Commit (aus welchem Grund auch immer) nicht stattfindet. Also wenn du mit dem Debugger rüber läufst, solltest du dir mal anschauen ob der irgendeine Stelle überspringt.
Die andere Sache ist noch, dass du nicht alle möglichen Exceptions abfängst. Da du kein throws eingetragen hast, geh ich mal davon aus, dass Hibernate an dieser Stelle keine Exceptions auslösen wird, aber ich persönlich würde einfach mal alle Exceptions abfangen (und mindestens loggen). Aber wie gesagt, sollte hier ja eigentlich nicht passieren können.

@Chewie, Eine Frage zu deiner Funktion isDebugEnabled(), ist dass eine statische final die eine Konstante zurückgibt? Da würde ich dich dann nämlich auch gleich fragen, ob du zufällig weißt, ob Java die dann schon zum bedingten Kompilieren benutzen kann? Also wenn man direkt eine Konstante nimmt ist es ja klar, aber mit einer Methode (sollte zwar, dumm ist Java ja nicht...)

Gruß Der Unwissende

[Edit]
Ahso, du schreibst ja, dass du gerne einen Denkanstoss zum Finden des Fehlers hättest, ganz überlesen. Ja, versuch es einfach mal mit einem Breakpoint. Also ich weiß nicht welche IDE du benutzt, aber es sollte von so ziemlich jeder unterstützt werden. Bei Eclipse findest du auch gleich eine sehr praktische Debug Ansicht. Hier kannst du dann auch den Wert von Variablen betrachten (was dir dann auch versteckte Nulls o.Ä. zeigt).
[/Edit]

[Chewie]

Zitat von Der_Unwissende:

@Chewie, Eine Frage zu deiner Funktion isDebugEnabled(), ist dass eine statische final die eine Konstante zurückgibt? Da würde ich dich dann nämlich auch gleich fragen, ob du zufällig weißt, ob Java die dann schon zum bedingten Kompilieren benutzen kann? Also wenn man direkt eine Konstante nimmt ist es ja klar, aber mit einer Methode (sollte zwar, dumm ist Java ja nicht...)

Du denkst zu weit isDebugEnabled() ist eine Methode der Commons Logging API von Apache, was ein Wrapper für verschiedene Logging-Frameworks darstellt. Die Logging-Konfiguration wird aber erst zur Laufzeit ermittelt, sodass das ein gewöhnlicher Methodenaufruf darstellt. In das Kompilat kommt die Abfrage also rein, man kann sie natürlich auch weg lassen, da log.debug() nur was schreibt, wenn das Level auf DEBUG steht. Von den Entwicklern wird die vorherhige Prüfung dann empfohlen, wenn sie im Vergleich zum Konstruieren der Logging-Ausagbe wesentlich weniger aufwändig ist. Ich schreib diese Abfrage aber grundsätzlich immer mit dazu, zumindest in nicht-zeitkritischen Sachen, weil man so den Logging-Aufruf weniger leicht übersieht.

[barnti]

Hi-ho,

Zitat von Der_Unwissende:

Hi,
ich kann dir zwar nicht direkt einen Tipp geben, aber bist du mal im Einzelschrittmodus durchgelaufen? Ich hab ein wenig die Vermutung, dass dein Commit (aus welchem Grund auch immer) nicht stattfindet. Also wenn du mit dem Debugger rüber läufst, solltest du dir mal anschauen ob der irgendeine Stelle überspringt.
Die andere Sache ist noch, dass du nicht alle möglichen Exceptions abfängst. Da du kein throws eingetragen hast, geh ich mal davon aus, dass Hibernate an dieser Stelle keine Exceptions auslösen wird, aber ich persönlich würde einfach mal alle Exceptions abfangen (und mindestens loggen). Aber wie gesagt, sollte hier ja eigentlich nicht passieren können.

Ich benutze Eclipse. Ich bin das bereits diverse male im Einzelschrittmodus durchgegangen. Jede Zeile wird wie erwartet ausgeführt. Die Exceptions habe ich mal auf alle HibernateExceptions erweitert:

Delphi-Quellcode:

public void persist(Rqs transientInstance) {
      log.debug("persisting Rqs instance");
      /**
       * ToDo
       */
      log.setLevel(Level.DEBUG);
      Transaction tx = null;
      try {
         tx = getCurrentSession().beginTransaction();
         getCurrentSession().save(transientInstance);//persist(transientInstance);
         tx.commit();
         log.debug("persist successful");
      } catch (HibernateException he) {
         log.error("persist failed", he);
         if(tx != null)
            tx.rollback();
         throw he;
      }
      finally{
         getCurrentSession().close();
      }
   }

Zitat:

[Edit]
Ahso, du schreibst ja, dass du gerne einen Denkanstoss zum Finden des Fehlers hättest, ganz überlesen. Ja, versuch es einfach mal mit einem Breakpoint. Also ich weiß nicht welche IDE du benutzt, aber es sollte von so ziemlich jeder unterstützt werden. Bei Eclipse findest du auch gleich eine sehr praktische Debug Ansicht. Hier kannst du dann auch den Wert von Variablen betrachten (was dir dann auch versteckte Nulls o.Ä. zeigt).
[/Edit]

Ja, das ist eine feine Sache. Leider hat mich das noch nicht weitergebracht

Danke für eure bisherigen Anregungen. Hatte mich schon gefreut, dass etwas helfen könnte. Leider noch nicht!
Andere Ideen?

[Chewie]

Funktioniert überhaupt das Zusammenspiel mit der Datenbank? Also kannst du Daten lesen? Und wenn ja, versuch mal die anderen Speichermechanismen (update(), save() etc.). Vielleicht liegt das Problem woanders.

[Der_Unwissende]

Sorry, schätze mal ich habe dich etwas in die Irre geführt. Mit den Hibernate Exception denke ich wirst du die Exceptions eher einschränken, nicht erweitern. Ich meinte eher ein

Code:

try
...
catch (Exception e) {
}

Es gibt noch Exceptions, die halt keine RuntimeException sind, aber gewurfen werden können. Die sollten zwar alle dann in einem throws aufgezählt oder mit einem catch abgefangen werden (hier sind RunTimeException imho die einzigste Ausnahme), aber man weiß ja nie. Als wenn du erweitert meinst, du kannst natürlich auch mehr als eine Sorte Exception abfangen, aber in deinem Code würdest du ja im Moment nur Hibernate Exceptions abfangen.

Ansonsten noch der Tipp, wenn du Code postest verwende einfach die Tags [c] und [ /c], da ist die Sprache deutlich näher an Java dran und der Code ist wieder sinnvoll vom Syntaxhighlightning.

[barnti]

Hallo ihr!

ich habs: Das mit dem Tip "wird nicht commitet" habe ich mir zu Herzen genommen. Ich habe mich gefragt, warum das sein könnte, da die betreffende Zeile durchlaufen wird. Hier die Antwort:

Delphi-Quellcode:

public void persist(Rqs transientInstance) {
      log.debug("persisting Rqs instance");
      Session s = getCurrentSession();
      /**
       * ToDo
       */
      log.setLevel(Level.DEBUG);
      Transaction tx = null;
      try {
         tx = s.beginTransaction();
         s.save(transientInstance);//persist(transientInstance);
         tx.commit();
         log.debug("persist successful");
      } catch (HibernateException he) {
         log.error("persist failed", he);
         if(tx != null)
            tx.rollback();
         throw he;
      }
      finally{
         s.close();
      }
   }

Vergleicht man hier mal den Aufruf zum Erhalt einer Session, erkennt man, dass hier mit Sicherheit nun auf dem selben Objekt gearbeitet wird. Vorher habe ich mir jedes Mal eine neue Session geben lassen!?!?!? Asche über mein Haupt!

Danke für eure Hilfe! Wieder einmal ist es dieses Forum, das den entscheidenden Hinweis liefert. Toll!
Vielen Dank an Der_"Unwissende" und vielen Dank auch an "Chewie". Bis bald!

[barnti]

Hi,

Zitat von Der_Unwissende:

Sorry, schätze mal ich habe dich etwas in die Irre geführt. Mit den Hibernate Exception denke ich wirst du die Exceptions eher einschränken, nicht erweitern. Ich meinte eher ein

Code:

try
...
catch (Exception e) {
}

Es gibt noch Exceptions, die halt keine RuntimeException sind, aber gewurfen werden können. Die sollten zwar alle dann in einem throws aufgezählt oder mit einem catch abgefangen werden (hier sind RunTimeException imho die einzigste Ausnahme), aber man weiß ja nie. Als wenn du erweitert meinst, du kannst natürlich auch mehr als eine Sorte Exception abfangen, aber in deinem Code würdest du ja im Moment nur Hibernate Exceptions abfangen.

Ansonsten noch der Tipp, wenn du Code postest verwende einfach die Tags [c] und [ /c], da ist die Sprache deutlich näher an Java dran und der Code ist wieder sinnvoll vom Syntaxhighlightning.

Du hast natürlich Recht. Ich werde mir die Stellen noch einmal vornehmen. Das mit den Code-Tags werde ich mir merken!

Vielen Dank noch einmal!