# Transaction RequiresNew Problem



## Pulpapex (10. Aug 2004)

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 (10. Aug 2004)

>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 (10. Aug 2004)

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





			
				Pulpapex hat gesagt.:
			
		

> [..] 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 (11. Aug 2004)

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 (11. Aug 2004)

Ü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 (18. Aug 2004)

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 (18. Aug 2004)

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 (23. Aug 2004)

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 (23. Aug 2004)

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


----------

