2016-07-25 27 views
4

Ich fand folgende Informationen aus der Spezifikation. Aber es ist mir nicht klar genug, wer kein Engländer ist.Ist @PostRemove aus der Transaktion entfernt?

Die PostPersist und PostRemove Methoden Rückruf sind für eine Entität aufgerufen, nachdem die Entität persistent gemacht oder entfernt worden ist. Diese Rückrufe werden auch für alle Entitäten aufgerufen, für die diese Operationen kaskadiert sind. Die Methoden PostPersist und werden nach dem Datenbankeinfüge- bzw. -löschvorgang aufgerufen. Diese Datenbankoperationen können direkt nach dem Aufrufen der Persistenz-, Zusammenführungs- oder Entfernungsoperationen oder direkt nach dem Auftreten einer Räumoperation (die am Ende der Transaktion sein kann) auftreten. Erstellte Primärschlüsselwerte sind in der PostPersist-Methode verfügbar.

Meine Frage ist jede Transaktion bezogene Aufträge können nach @PostRemove zurückgesetzt werden?

Lassen Sie uns sagen, dass meine Einheit löscht einige Offline-Dateien auf @PostRemove

class MyEntity { 

    @PostRemove 
    private void onPostRemove() { 
     // delete offline files related to this entity 
     // not restorable! 
    } 
} 

Ist es möglich, dass diese Offline-Dateien aus dem Speicher gelöscht und das Unternehmen noch in der Datenbank nach links? (von Rollback?)

+0

Scheint im Zusammenhang mit: http://stackoverflow.com/questions/4895854/jpa-postpersist-postupdate-transaction?rq=1 – MWiesner

Antwort

3

Ja, es ist möglich, dass Ihre Dateien gelöscht werden und Ihre Daten nach einem Rollback noch in db verbleiben. @PostRemove ist in Transaktion.

Wenn Sie absolut sicher sein möchten, dass Ihre Dateien genau dann gelöscht werden, wenn die Transaktion erfolgreich abgeschlossen wurde, sollten Sie die Dateien löschen, nachdem die commit() die Rückrufmethoden nicht erfolgreich verwendet. Aber wenn Sie auch sicher sein müssen, dass die Entität genau dann entfernt wird, wenn die Datei gelöscht wird, dann haben Sie ein Problem. Sie benötigen eine transaktionale Zugriffsmöglichkeit auf das Dateisystem.

Für eine einfache Lösung verschieben Sie Ihre Dateien in einen to_be_deleted -Ordner während der DB-Transaktion. Daher können Sie die Callback-Methoden verwenden. Die Dateien werden endgültig gelöscht, wenn commit() erfolgreich ist und bei einem Fehler wiederhergestellt wurde.

Wenn Sie es ein bisschen mehr ausarbeiten möchten und Ihre Anwendung in einem Java-EE-Container ausgeführt wird, dann können Sie sich CDI events oder sogar eine jca adapter ansehen. Wenn Sie Spring verwenden, können Sie eine TransactionSynchronizationAdapter registrieren, siehe this answer.

1

Es kommt darauf an.

Wenn Sie mehrere Flushes verwenden (EntityManager#flush()), kann die Transaktion immer noch zurückgesetzt werden. Andernfalls werden alle Callbacks mit dem Präfix Post ausgeführt, nachdem die Datenbanktransaktion abgeschlossen ist.

+0

Verwendung der 'PreXXX'-Callbacks macht keinen Sinn. Die Dateien werden zu einem Zeitpunkt gelöscht, an dem die Transaktion fehlschlagen kann. – frifle

+0

Sie haben Recht. Habe dem speziellen Anwendungsfall nicht genug Aufmerksamkeit geschenkt. Aktualisiert. – fny