Spring3s @Transactional @Scheduled nicht an DB gebunden?

8

Dies ist das erste Mal, dass ich Spring3's @Scheduled versuche, aber ich kann mich nicht auf DB festlegen. Das ist mein Code:

%Vor%

Ich denke, es sollte funktionieren, ich kann sehen, dass es stündlich startet und xxx aus der DB lädt, aber die Daten sind nicht an die DB gebunden.

Es gab tx:annotation-driven im Frühling xml:

%Vor%

Kann mir jemand sagen, was ich hier verpasst habe?

Ich habe eine dreckige Lösung:

%Vor%

Es funktioniert hier , aber es ist so redundant, dass der Code schwerer zu lesen ist. Ich frage mich, warum TransactionManager in den vorherigen Code-Snippets nicht eingefügt (und geöffnet) wurde?

Vielen Dank!

    
smallufo 26.03.2011, 17:12
quelle

3 Antworten

17

Sie haben das wahrscheinlich herausgefunden oder sind weitergegangen (hoffe ich), aber zum Vorteil anderer:

Die @Transactional Annotation weist Spring an, die ursprüngliche ServiceImpl -Bohne mit einem dynamischen Proxy zu umhüllen, der auch ' Service ' implementiert (standardmäßig gibt Spring die Schnittstelle und nicht die Implementierung an). Dieser Proxy wird die Erstellung und das Commit / Rollback der Transaktion transparent verarbeiten, wenn Sie hourly() auf dem Proxy aufrufen. Wenn Sie jedoch hourly() direkt auf Ihrer Implementierung aufrufen (was oben passiert), wird der Proxy umgangen, so dass es keine Transaktion gibt.

Ссылка

Die Lösung ist entweder

  1. Abgrenzung der Transaktion programmgesteuert, wie Sie es in Ihrer "schmutzigen" Lösung tun (Sie brauchen die Anmerkungen in diesem Fall nicht).
  2. Stellen Sie sicher, dass Ihre @Scheduled-Methode über die Service-Schnittstelle zu dao.update(xxx); aufruft, nicht direkt auf Ihrer Implementierung (wodurch der Proxy durchlaufen wird). Grundsätzlich müssen Sie die Methode @Scheduled auf eine andere Bean verschieben.

Ich hoffe, das ist klar genug!

    
Barry Pitman 18.10.2012 14:53
quelle
0

Wenn Sie Annotation-basierte Unterstützung verwenden, funktioniert sie nur für Klassen, die in diesem Kontext erstellt wurden. Meine Wette ist, dass ServiceImpl nicht in demselben Kontext wie Ihr Transaktionsmanager erstellt wird (entweder direkt oder durch Annotationsscannen).

    
Andrew White 26.03.2011 17:19
quelle
0

Ich hatte das gleiche Problem und nach einiger Zeit erkannte ich, dass ich nach dem Aufruf von dao.update () in einem nicht verwandten Code, der den Nullwert nicht überprüft hatte, eine Ausnahme bekam. Es gab kein stackTrace-Drucken, da es im Frühjahr gut behandelt wurde (einige Catch-Blöcke). Ich habe eine Weile damit verbracht. Überprüfen Sie also, ob Ihre Transaktionsmethode bis zu ihrem Ende abgeschlossen ist. Ich hoffe, es wird jemandem helfen.

Yosi Lev

    
ylev 26.04.2015 16:48
quelle