@OneToMany Persistence Set wird für einige Entitäten nicht abgerufen

Question

Ich habe eine Weile nach einer Lösung für mein Problem gesucht, und bin derzeit fest.

Ich habe eine Spring-Batch-Anwendung, die Elemente aus meiner Datenbank abruft, um sie zu löschen. Der Stapel funktioniert problemlos in 3 von 4 Umgebungen (lokaler Computer, Testserver usw.).

Testen der Datenbank auf dem K.O. Server mit der Anwendung auf meiner Maschine macht das gleiche. (Und der Code ist bereits derselbe in allen 4 Instanzen).

Hier ist, was passiert: meine Charge

Mein erstes Objekt

@Table(name = "TABLE_1") 
public class Object1 { 
    ... 
    @OneToMany(mappedBy="object1") 
    private Set<Object2> myObj2 = new HashSet<Object2>(); 
} 

Mein zweites Objekt

@Table(name = "TABLE_2") 
public class Object2 { 
    ... 
    @NotNull 
    @ManyToOne 
    @Index(name = "FK_TABLE_1") 
    @JoinColumn(name = "TABLE_1_ID", referencedColumnName = "id") 
    private Object1 obj1; 
} 

So, jetzt logisch bekommen, Object1 (um genau sein muss ich ein ParentObject, die mehrere Object1 Entitäten enthalten) mit der Liste Object2, so dass ich sie löschen kann (mit entity.remove(), nichts Brauchbares).

Dies funktioniert jedoch nicht vollständig auf einem Server, insbesondere auf einer Entität (vielleicht gibt es andere, aber der Batch löst auf dieser Ebene eine Ausnahme aus).

Ich habe die Datenbankeinschränkungen, Daten und alles überprüft, was ich überprüfen konnte, und die Datenbank ist praktisch identisch, also sollte es keinen Grund geben, dass diese Entity/die Zeilen in den Tabellen nicht gelöscht werden.

Spring-Batch-Chunk-Größen sind auf jedem Server/jeder Maschine, die den Batch ausführt, identisch. Die gleiche Version von Java wird sicher verwendet (die pom.xml-Dateien sind identisch).

Jede Hilfe und/oder Ideen sind sehr willkommen. Danke.

Edit 1: Passwort Ausnahme:

USER.FK_FROM_TABLE_2: ein Fremdschlüssel, der sagt: table_1 (die ID) muss in table_2

 
org.springframework.dao.DataIntegrityViolationException: could not delete: [Object1#14382]; SQL [delete from table_1 where id=? and version=?]; constraint [null]; 
    nested exception is org.hibernate.exception.ConstraintViolationException: could not delete: [Object1#14382] 
    at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:643) 
.. 
    at fr.covea.troisma.soja.batch.BatchService.launchJob(BatchService.java:69) 
    at fr.mma.soecm.batchpurgedonnees.Main.main(Main.java:89) 
Caused by: org.hibernate.exception.ConstraintViolationException: could not delete: [Object1#14382] 
    at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:96) 
.. 
    at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:76) 
    at org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:512) 
    ... 22 more 
Caused by: java.sql.SQLException: ORA-02292: constraint violation (USER.FK_FROM_TABLE_2) - enregistrement fils existant 

    at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) 
.. 
    at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2711) 
    ... 34 more 
14:42:48,480 ERROR [] [AbstractStep] - Encountered an error saving batch meta data. This job is now in an unknown state and should not be restarted. 
org.springframework.dao.OptimisticLockingFailureException: Attempt to update step execution id=1 with wrong version (1), where current version is 2 
.. 
    at fr.mma.soecm.batchpurgedonnees.Main.main(Main.java:89) 
14:42:48,481 ERROR [] [Main] - Batch does not complete successfuly: status=UNKNOWN 

Answer 1

Ich reparierte verwiesen werden habe Dieses Problem durch Löschen der "falschen Daten" aus der Datenbank.

Während dies nicht die ideale Lösung ist, hat ein Kollege das Problem wahrscheinlich gelöst und mir eine 'Persistenz-Theorie' gegeben.

Seine Idee ist, dass die Datensätze von Object2, die nicht wiederhergestellt wurden, wo tatsächlich von einem anderen Benutzer manuelle Eingabe beschädigt.

Da es keine anderen Anzeichen dafür gibt, dass die Datenbank durch unseren Code geändert wurde, und da die Datenbank durch eine Persistenz-API verändert wird, muss die interne Datenbankregistrierung nicht mit der tatsächlichen Datenbank übereinstimmen.

Um klarer zu sein: Wenn die (zB) Spalte "VERSION" in der Registrierung auf "2" gesetzt ist/wurde, die Datenbank enthält "0", dann werden die Java-Objekte nicht wiederhergestellt. Es ist außerdem unmöglich für uns/mich zu sagen, was im Hinblick auf "Persistenz-sensible Felder" geändert wurde, so dass wir nur feststellen können, dass dies ein menschlicher Fehler war.

Ich hoffe, dass dies auch jemand anderen hilft.