org.hibernate.AssertionFailure: NULL-ID im Eintrag (Die Sitzung darf nicht geleert werden, wenn eine Ausnahme auftritt)

Die Ausnahme:

org.hibernate.AssertionFailure: NULL-ID im Eintrag (Die Sitzung darf nicht geleert werden, wenn eine Ausnahme auftritt)

Teilt uns mit, dass die Sitzungsausnahme stattgefunden hat vorher der Punkt, an dem dieses org.hibernate.AssertionFailure geworfen wird.

Um genau zu sein, wird org.hibernate.AssertionFailure ausgelöst, wenn die session.flush() stattfindet, nicht der Punkt, an dem der Fehler aufgetreten ist.

Das Obige ist eine Tatsache, daher ist eine mögliche Schlussfolgerung daraus: Etwas könnte unterdrückend die ursprüngliche Ausnahme sein.

Suchen Sie also nach other möglichen Fehlerpunkten: Eine save() oder saveOrUpdate() ist möglicherweise versucht, eine Entität mit einem null-Feld zu persistieren wobei die Spalte in der Tabelle NOT NULL ist?

TIP: Um beim Debuggen zu helfen, fügen Sie nach jeder Interaktion mit dem Session-Objekt (z. B. session.flush(), session.save(obj) usw.) eine session.merge(obj) hinzu. Dies führt hoffentlich dazu, dass org.hibernate.AssertionFailure früher passiert wo das eigentliche Problem stattfindet. (Natürlich entfernen Sie nach dem Debuggen diese session.flush().)

In meinem Fall fand die real -Exception in einem try/catch {}-Block statt, in dem die catch die Exception unterdrückt hat (hat nicht erneut geworfen oder mich darüber gewarnt).

Ich würde für ein Parallelitätsproblem wetten, aber es kann auf verschiedenen Ebenen auftreten:

• eine Ruhezustandsitzung kann von verschiedenen Benutzern gemeinsam genutzt werden, wenn das classic-Muster "offene Sitzung in Ansicht" nicht ordnungsgemäß implementiert ist
• eine Entität wird von zwei Benutzersitzungen aufgrund falscher hibernate Cache-Einstellungen gemeinsam genutzt .
• eine JDBC-Verbindung wird von zwei verschiedenen Hibernat-Sitzungen gemeinsam genutzt (weniger wahrscheinlich).

Abgesehen von diesen potenziellen Problemquellen würde ich c3p0 entfernen (vielleicht nur Gerüchte ...), da Ihr Stack DataSource bereits ein Verbindungspooling mit dem Transaktionsmanager bereitstellt.

Der @asdcjunior hat richtig geantwortet. Etwas ist geschehen, bevor die Ausnahme ausgelöst wird.

In dieser Art von Situationen (bei Integrationsprüfungen kommt es häufig vor, wenn Sie eine einzelne Transaktion für einen Test ausführen (z. B. @Transaction-Annotation). Ich rufe die Methode auf:

session.clear()

Dies ist hilfreich, da alle 'schmutzigen' Objekte aus der aktuellen Sitzung entfernt werden. Wenn das nächste Flush ausgeführt wird, tritt das Problem nicht auf.

Beispielablauf:

• füge die Zuweisungsentität ein (Viele-zu-Viele-Beziehung mit Einschränkung, die möglicherweise nur eine Zuweisung enthält) -> alles ok
• füge dieselbe Zuweisung noch einmal ein -> alles in Ordnung, Controller in diesem Fall eine Art schlechte Anforderungsausnahme zurückgeben. Spring wirft die IntegrityViolationException unter die Haube -> im Test sieht alles in Ordnung aus
• holen Sie sich das Repository und führen Sie findAll (). size () aus, um die Anzahl der vorhandenen Zuweisungen zu überprüfen, um sicherzustellen, dass nur eine einzelne Zuweisung vorliegt -> die erwähnte Ausnahme wird ausgelöst;/Was ist passiert? In der Sitzung gibt es immer noch ein fehlerhaftes Objekt. Normalerweise würde die Sitzung zerstört werden (Controller-Rückgabefehler). Hier haben wir jedoch die nächsten Assertions, die in Bezug auf die Datenbank geprüft werden sollen. Die Lösung hier ist eine zusätzliche session.clear () vor der Ausführung der nächsten db-bezogenen Methode 

Beispiel für einen korrekten Fluss:

• fügen Sie die Zuweisungsentität ein
• füge dieselbe Zuordnungsentität ein
• session.clear ()
• holen Sie sich das Repository und führen Sie findAll () aus. size ()

Ich hoffe es hilft ;)

Sie schlagen wahrscheinlich einen Hibernate-Fehler. (Ich empfehle ein Upgrade auf mindestens Hibernate 3.3.2.GA.) 

In der Zwischenzeit ist Hibernate besser, wenn Ihre ID nullfähig ist, sodass Hibernate immer den Unterschied zwischen einem neuen Objekt, das noch nicht in der Datenbank gespeichert wurde, und einem bereits in der Datenbank vorhandenen unterscheiden kann. Das Ändern des Typs von addressID von long in Long wird das Problem möglicherweise umgehen. 

Die von Ihnen bereitgestellte Stack-Ablaufverfolgung zeigt, dass das Problem in einer Abfrage angezeigt wird, da die Abfrage das Speichern von gepufferten Schreibvorgängen in die Datenbank erzwingt, bevor die Abfrage ausgeführt wird und der Schreibvorgang fehlschlägt, möglicherweise mit demselben Einfügeproblem, das andere Benutzer sehen. 

Ich stand vor diesem Problem Ich füge nur try catch block hinzu und in catch block schrieb ich seesion.clear (); Jetzt kann ich mit dem Rest der Datensätze fortfahren, um sie in die Datenbank einzufügen

Herzliche Grüße: Shahid Hussain Abbasi

Problemfluss:

1. Sie erstellen eine neue Instanz der transienten Entität (hier eine Address-Instanz)
2. Sie bleiben in der Datenbank gespeichert (mithilfe von "Sichern", "Zusammenführen" oder "Persistieren" im Ruhezustand von Session/JPA EntityManager).
3. Da der Entitätsbezeichner von der Datenbank im Ruhezustand generiert wird, muss die Datenbankeinfügung ausgelöst werden (die Sitzung wird geleert), um die generierte ID abzurufen
4. Die Einfügeoperation löst eine Ausnahme aus (oder eine ausstehende nicht gelöschte Änderung in der Sitzung).
5. Sie fangen die Ausnahme ab (ohne sie zu verbreiten) und setzen den Ausführungsablauf fort (zu diesem Zeitpunkt enthält Ihre Sitzung immer noch die nicht persistierte Instanz ohne die ID. Das Problem besteht darin, dass der Hibernate die Instanz als verwaltet betrachtet, die Instanz jedoch als verwaltetes Objekt beschädigt muss eine id haben
6. wenn Sie das Ende Ihrer Arbeitseinheit erreicht haben und die Sitzung automatisch geleert wird, bevor die aktuelle Transaktion festgeschrieben wird, schlägt der Flush mit einem Assertionsfehler fehl, da die Sitzung eine beschädigte Instanz enthält

Sie haben viele Möglichkeiten, diesen Fehler zu mindern: 

• Einfachste und als Ruhezustand steht "Sitzung nicht ausspülen, wenn eine Ausnahme auftritt", dh. sofort aufgeben und die aktuelle Transaktion nach einer Persistenzausnahme rückgängig machen.
• Entfernen Sie die beschädigte Instanz manuell von der Sitzung, nachdem Sie den Fehler abgefangen haben (an Punkt 5, aber wenn der Fehler durch eine andere ausstehende Änderung anstelle der Entitätseinfügung selbst ausgelöst wurde, ist dies nutzlos.)
• Lassen Sie nicht zu, dass die Datenbank die ID-Generierung übernimmt (verwenden Sie die UUID oder ein verteiltes ID-Generierungssystem. In diesem Fall wird der endgültige Flush den echten Fehler auslösen, der die Persistenz der neuen Instanz verhindert, anstelle eines Überbrückungsversagens).

Beim Erstellen von session.getCurrentSession.refresh (entity) tritt derselbe Fehler auf, der mir eher nach einem Fehler aussieht als nach einem Problem mit meinem Code. Ich erhalte diesen Fehler in einem Komponententest, wenn ich zu Beginn eines Tests versuche, eine Entität zu aktualisieren, und diese Entität im Test-Setup erstellt wird (mit @Before von junit kommentiert). Was seltsam ist, ist, dass ich 3 Entitäten aus derselben Klasse mit zufälligen Daten zur selben Zeit und auf dieselbe Weise im Setup erstelle und die ersten beiden erstellten aktualisieren kann, aber die Aktualisierung für die letzte fehlschlägt. Wenn ich zum Beispiel 3 Entitäten Benutzer im Test-Setup erstelle, kann ich Benutzer1 und Benutzer2 aktualisieren und dies schlägt für Benutzer3 fehl. Ich konnte dies beheben, indem ich session.flush () am Ende des Codes hinzufügte, der die Entität im Setup erstellt. Ich bekomme keine Fehler und sollte es tun, aber ich kann nicht erklären, warum die zusätzliche Spülung erforderlich ist. Außerdem kann ich bestätigen, dass sich die Entitäten auch ohne Flush tatsächlich in der Test-DB befinden, da ich sie im Test abfragen kann, die Aktualisierungsmethode (Entität) jedoch weiterhin fehlschlägt.

Dies geschieht manchmal, wenn die Länge der Zeichenfolge größer ist als die von DB zulässige Länge.

DataIntegrityViolationException übersetzt diese Ausnahme, die durch den Ruhezustand ein seltsames Verhalten darstellt.

Wenn Sie also eine Column-Annotation für das String-Feld der Entität mit der angegebenen Länge haben und der tatsächliche Wert größer als diese Länge ist, wird die obige Ausnahme ausgelöst.

Ref: https://developer.jboss.org/thread/186341?_sscc=t

Ändern der Generatorklasse: 

<generator class="identity" />

zu

<generator class="assigned" />

org.hibernate.AssertionFailure: NULL-ID im Eintrag (Die Sitzung darf nicht geleert werden, wenn eine Ausnahme auftritt)

Das ist uns gerade passiert und ich dachte, ich würde ein paar Details für die Nachwelt hinzufügen. Es stellt sich heraus, dass wir versucht haben, eine Entität mit einem doppelten Feld zu erstellen, das gegen eine Bedingung verstößt:

Caused by: org.hibernate.exception.ConstraintViolationException: Duplicate entry '' for key
'Index_schools_name'

Diese Ausnahme wurde jedoch maskiert, weil der Ruhezustand versucht hatte, die Sitzung commit zu übergeben, obwohl das Erstellen fehlgeschlagen ist. Wenn der erstellte Fehler fehlgeschlagen ist, wurde die ID nicht gesetzt, daher der Assert-Fehler. In der Stapelverfolgung konnten wir feststellen, dass der Winterschlaf begangen wurde:

at org.springframework.orm.hibernate4.HibernateTransactionManager.doCommit
(HibernateTransactionManager.Java:480)

Es hätte die Sitzung zurücksetzen sollen, ohne sie zu begehen. Dies stellte sich als Problem bei unserer Rollback-Konfiguration heraus. Wir verwenden die alten XML-Konfigurationen und der Ausnahmepfad war falsch:

<prop key="create*">PROPAGATION_REQUIRED,-org.x.y.LocalException</prop>

Der LocalException-Pfad war falsch und der Ruhezustand hat keinen Fehler ausgelöst (oder er wurde in der Startprotokollspur vergraben). Dies wäre wahrscheinlich auch der Fall, wenn Sie die Annotationen verwenden und nicht die richtigen Ausnahmen angeben:

// NOTE: that the rollbackFor exception should match the throws (or be a subclass)
@Transactional(rollbackFor = LocalException.class)
public void create(Entity entity) throws AnotherException {

Nachdem wir die Verdrahtung für den Ruhezustand behoben hatten, sahen wir die Ausnahme "Eintrag duplizieren" richtig und die Sitzung wurde ordnungsgemäß zurückgesetzt und geschlossen.

Ein weiteres Problem bestand darin, dass der Hibernate, wenn die AssertionFailure geworfen wurde, eine Transaktionssperre in MySQL hielt, die dann von Hand getötet werden musste. Siehe: https://stackoverflow.com/a/39397836/179850

Dies hat nichts mit der gerade ausgeführten Abfrage zu tun. Dies löst nur die Spülung aus. An diesem Punkt versucht Hibernate der Entität eine Kennung zuzuweisen und scheint aus irgendeinem Grund fehlgeschlagen zu sein.

Könnten Sie versuchen, die Generatorklasse zu ändern:

<generator class="identity"/>

sehen Sie, ob das einen Unterschied macht. Haben Sie auch sichergestellt, dass für die bereitgestellte Datenbank die richtige Spalte für die automatische Erhöhung der Tabelle eingerichtet wurde?

Es klingt, als wäre Ihr Problem ähnlich wie dieses .

Ich habe auch die gleiche Ausnahme in der Hibernate-Konfigurationsdatei:

<property name="operateType" type="Java.lang.Integer">
        <column name="operate_type" not-null="true" />
 </property>

beim Übergeben eines Nullwerts am Objekt tritt eine Ausnahme auf

 "org.hibernate.AssertionFailure: null id in com.idex.auctions.model.Address entry",

Ich denke, der Grund dafür ist, dass Hibernaye die 'not-null'-Eigenschaft überprüft. Entfernen Sie also die' not-null'-Eigenschaft oder setzen Sie 'not-null' für 'false', um das Problem zu lösen.

OK, ich habe weiter nach anderen Antworten in diesem Thread gesucht. Aber am Ende, da wir einen Produktionsstermin hatten, musste ich die Notfallroutine wählen. Anstatt den Winterschlaf herauszufinden, tat ich diese beiden Dinge: 

1. Eine jQuery-Bibliothek entfernt, mit der ich mich auf eines der Formulare konzentrierte. Ich habe dies getan, weil ich irgendwo gelesen habe, dass diese Art von Fehler auftreten kann, weil ein Formular einen Nullwert bereitstellt - die Null-ID in der Zeile verursacht wird. Ich hatte den Verdacht, dass die jQuery-Bibliothek möglicherweise nicht gut mit PrimeFaces zusammenarbeitet und zu einer Fehlfunktion der Form führt. Nur eine Ahnung. 

2. Ich habe die durch den Ruhezustand implementierte Beziehung zwischen Benutzer und Adresse abgebrochen. (nur einer erforderlich, nicht einer zu vielen) und schrieb den Code bei Bedarf selbst. Glücklicherweise hat es nur eine Seite stark beeinflusst, daher war es nicht viel Arbeit. 

Fazit: Wir sind live gegangen und die Anwendung läuft seit mehreren Tagen fehlerfrei. Diese Lösung mag also nicht schön sein - und ich bin nicht stolz auf mich -, aber ich habe eine laufende App und einen glücklichen Kunden. 

Ich hatte den gleichen Fehler. In meinem Fall lag es daran, dass vor dieser Ausnahme eine Abfrage mit Ausnahme erstellt wurde. Ausnahme wird abgefangen und die Transaktion wird nicht im catch-Block zurückgesetzt. Dann benutze ich diese kaputte Transaktion in einer anderen Operation und nach ein paar Mal bekam ich die gleiche Ausnahme. Zuerst setze ich den Spülmodus auf manuell 

public final Session getCurrentSession()  
{
    Session session = sessionFactory.getCurrentSession();
    session.setFlushMode(FlushMode.MANUAL);
    return session;
}

Dann bekam ich eine weitere Ausnahme, die mir erklärte, was tatsächlich geschah. Dann habe ich ein Transaktionsrollback im catch-Block meiner create-Methode durchgeführt. Und es hat mir geholfen.

org.hibernate.AssertionFailure: NULL-ID im Eintrag (Die Sitzung darf nicht geleert werden, wenn eine Ausnahme auftritt)

Sie erhalten diesen Fehler, während Sie die Speichermethode verwenden, wenn Sie den Versionsverlauf der Benutzeraktivität beibehalten und versuchen, die folgenden Werte festzulegen. setCreatedBy(1); setModifiedBy(1); setCreationDate(); setChangeDate();} Sie erhalten den obigen Fehler, um dieses Problem zu lösen. Sie müssen die folgenden Spalten für die Tabelle erstellen.

Created_By Modified_By Creation_Date Change_Date wenn Sie denselben Fehler während der Update-Methode erhalten, um dieses Problem zu lösen Sie müssen lediglich die Update () -Methode in die merge () -Methode ändern, die es