Transaction RequiresNew Problem

[Pulpapex]

Hallo,

Ich habe ein Problem mit dem "RequiresNew" Attribut für Transaktionen. Folgende Konstellation: JBoss 3.2.1 Server mit DB2 local-tx-datasource (Treiber: db2jcc.jar), Hibernate 2.1 und CMT-SessionBeans. Eine Methode mit "Required" Attribut ruft eine Methode mit "RequiresNew" Attribut auf. Der Aufruf erfolgt natürlich über das EJBObject (in meinem Fall ein EJBLocalObject).

Wenn die Transaktion der aufrufenden Methode mit setRollbackOnly zurückgerollt wird, sollte man doch annehmen, dass Änderungen, die in der aufgerufenen Methode vorgenommen wurden, davon nicht betroffen sind. Auf Grund des "RequiresNew" Attributs sollte die Methode ja in einer eigenen Transaktion laufen. Das ist aber leider nicht der Fall. Ein Rollback macht bei mir immer alle Änderungen rückgängig.

Das Ganze nochmal in Pseudo-Code:

[Required]
methodA() {

    // Business-Data lesen/schreiben.

    [RequiresNew]
    methodB() {
        // Logmeldungen schreiben.
        // Sollen auch bei einem Rollback in methodA erhalten bleiben.
    }

    // Transaktion zurückrollen.
    // Macht seltsamerweise auch die in methodB 
    // vorgenommene Änderungen  rückgängig.
    getSessionContext().setRollbackOnly();
}

Bemerkung:
Den Log-Ausgaben zufolge, verläuft alles nach Plan: Für methodB erscheint eine Meldung mit Transaction Status 4 (javax.transaction.Status.STATUS_COMMITTED). Kurz darauf folgt die Meldung für methodA mit Transaction Status 3 (javax.transaction.Status.STATUS_ROLLEDBACK).

Kennt jemand dieses Verhalten? Ich schätze, dass es mit DB2 zusammenhängt ... aber kann alles mögliche sein ;-)

Gruß
Pulpapex

 

[semi]

>Eine Methode mit "Required" Attribut ruft eine Methode mit "RequiresNew" Attribut auf.
Wenn Du es direkt tust,
z.B.

public void a() // mit "required" TX-Attribut
{
  b();
}

public void b() // mit "requiresNew" TX-Attribut
{
  ...
}

dann werden beide im gleichen Transaktionskontext ausgeführt.
Klartext: Beide "required" innerhalb einer und der gleichen Transaktion.
Oder anders ausgedrückt, einfach ein Methodenaufruf in der aktuellen Klasse.

Du musst für diesen Fall (den Methodenaufruf) eine neue Session erzeugen.

Gruß,
Michael

 

[Guest]

Semi,
das ist es nicht. Ich hab doch geschrieben:

[..] Der Aufruf erfolgt natürlich über das EJBObject (in meinem Fall ein EJBLocalObject).

Ich rufe also auf:

getSessionContext().getEJBLocalObject().methodB();

Dieser Aufruf erfolgt über einen von JBoss bereitgestellten Proxy und läuft damit durch den Container. Ich kann mir nicht vorstellen, dass es nötig ist, über das Home-Interface eine neue Session zu öffnen.

 

[semi]

Sorry, ich habe Deine Frage zu oberflächlich gelesen.
Bist Du 100% sicher, dass der Deployment-Descriptor korrekt ist?

Ich habe Dein Szenario mit SAPDB und HSQLDB (bei jboss dabei)
nachgemacht (DB2 habe ich nicht) und es funktionierte bei beiden
Datenbanken einwandfrei. Alle Änderungen in der "RequiresNew"-Methode
wurden übernommen, der Rest (vom Aufrufer) verworfen.

Bei SAPDB habe ich auch die Möglichkeit ein Trace der DB-Server Aktivitäten
zu loggen. Da sehe ich, dass die Transaktionen verschachtelt sind.

Es sind immer wieder die kleinen Fehler, die einen auf die Palme bringen. Was?
Sorry DB2 kenne ich nicht, um irgendwas schlaues darüber zu sagen.
Versuche vielleicht eine andere Datenbank (Test mit HSQLDB ist schnell eingerichtet)
und wenn es läuft, dann weisst Du zumindest dass es an DB2 oder dem
dazugehörigen JDBC-Treiber liegt.

Gruß,
Michael

 

[semi]

Übrigens, MySQL 4.0.12 mit InnoDB funzt auch.
Es muss an Deinen Einstellungen liegen. Ich kann
mir nicht vorstellen, dass DB2 sowas nicht unterstützt.

Sag' bitte Bescheid, wenn Du die Lösung hast.
Die Ursache, wenn Datenbankseitig, würde mich auch interessieren.

Gruß,
Michael

 

[Pulpapex]

Hat ein bisschen länger gedauert. Ich hab's jetzt auch mit MySQL 4.0.xx ausprobiert, funktioniert auch nicht. Ich hab keinen Schimmer woran es liegen könnte. Hier mal der Deployment Descriptor, den ich verwende, in einer vereinfachten Form. Soweit ich weiss gibt es im JBoss-Deployment-Descriptor keine weiteren Einstellungen für Transaktionen:

<ejb-jar>
	<enterprise-beans>

		
		<session>
			<display-name>Import-Local</display-name>
			<ejb-name>ImportLocal</ejb-name>
			<local-home>ejb.ImportLocalHome</local-home>
			<local>ejb.ImportLocal</local>
			<ejb-class>ejb.ImportLocalBean</ejb-class>
			<session-type>Stateless</session-type>
			<transaction-type>Container</transaction-type>

			<resource-ref>
				<res-ref-name>hibernate/SessionFactory</res-ref-name>
				<res-type>net.sf.hibernate.SessionFactory</res-type>
				<res-auth>Container</res-auth>
			</resource-ref>
		</session>

	</enterprise-beans>

	<assembly-descriptor>

		
		<container-transaction>
			<method>
				<ejb-name>ImportLocal</ejb-name>
				<method-name>*</method-name>
			</method>
			<trans-attribute>Required</trans-attribute>
		</container-transaction>

		
		<container-transaction>
			<method>
				<ejb-name>ImportLocal</ejb-name>
				<method-name>saveImportStatus</method-name>
				<method-params>
					<method-param>vo.ImportStatus</method-param>
				</method-params>
			</method>
			<trans-attribute>RequiresNew</trans-attribute>
		</container-transaction>

	</assembly-descriptor>
</ejb-jar>

Wie gesagt verwende ich JBoss 3.2 und Hibernate 2.1. Hibernate macht nichts mit Transaktionen und überlässt alles JTA.


Gruß
Pulpapex

 

[semi]

Der deployment descriptor sieht gut aus.
Ich kann auch keinen Fehler erkennen.
Ich habe es mit JBoss 3.0.0 und 3.2 versucht, bei beiden
hat's funktioniert. ???:L

Versuche mal das hier
http://home.arcor.de/mise/public/txtest.zip
Im Unterverzeichnis deploy steht die JAR'-Datei, die Du direkt
deployen kannst.
Es erstellt eine Tabelle "Test" mit den Feldern "ID" und "Name".
Stelle in jboss3.2\server\default\conf\standardjbosscmp-jdbc.xml
<create-table>true</create-table> ein.
exec-test.bat führt das Testprogramm aus.

Wenn nach der Ausführung 100 Datensätze mit dem Namen "testRequiresNew()"
drin stehen, dann ist es korrekt gelaufen.
Wenn nicht, dann geht die Suche nach Konfigurationsfehlern weiter

PS: Das ganze ist größtenteils aus einer IDE (JDeveloper) heraus generiert,
vergiss also die Formatierung

Gruß,
Michael

 

[Pulpapex]

Ich hab dein Test-Programm ausprobiert, hab es einmal für BMP und einmal für Hibernate umgeschrieben. Funktioniert mit MySQL und auch mit DB2. Wahrscheinlich liegt es an der Hibernate-Session, die ich in der Required-Methode öffne und in der RequiresNew-Methode weiterverwende. Die Hibernate-Doku sagt zwar, eine Session kann für mehrere Transaktionen verwendet werden, aber scheinbar ist das nicht immer der Fall.

Ich hab im Netz eine Lösung gefunden, die automatisch für jede JTA-Transaktion eine neue Session öffnet. Bin ich noch am Ausprobieren ob das funktioniert.

Link: Reuse Hibernate Session instances within a transaction

Gruß
Pulpapex

PS: was ist denn mit dem Deployment Descriptor in meinem letzten Post passiert? Sah schon mal besser aus.

 

[semi]

OK, dann kann man Datenbank-/Treiberfehler ausschliessen.
Mit Hibernate habe ich noch nie etwas gemacht, daher fällt mir
dazu nichts ein.
Ein Arbeitskollege macht was mit Struts aber Hibernate ist bei uns
nicht mal in Planung. CMP verwenden wir momentan ebenfalls nicht
(nur BMP) um "notfalls" die Persistenzschicht schnell auswechseln zu
können.

Gruß,
Michael