RE: [Springframework-developer] Transaction support

[<jue...@we...>]

Hi Rod,

I've just seen your modifications to TransactionInterceptor. You've =
added explicit programmatic rollback handling, i.e.

	if (status !=3D null && !status.isRollbackOnly()) {
		// Normal course of transaction: commit
		doCommit();
	}
	else {
		// Handle programmatic rollback
		doRollback();
	}

where doCommit and doRollback call PlatformTransactionManager's commit =
and rollback, respectively. Technically, this isn't necessary, as the =
PlatformTransactionManager implementation is supposed to handle this. =
That way, every transaction manager client can benefit from it =
implicitly. Unfortunately, PlatformTransactionManager's documentation =
currently doesn't state that, so I will add appropriate JavaDoc.

By deriving from AbstractPlatformTransactionManager instead of =
implementing PlatformTransactionManager directly, a transaction manager =
implementation can benefit from the former's programmatic rollback and =
propagation behavior handling. A subclass just needs to implement =
doCommit, doRollback, etc without having to care about such case =
handling that will normally be the same (see JtaTransactionManager).

All things considered, I suggest to remove the explicit check above if =
you don't mind, as it is unnecessary.=20

Generally, what do you think of the current state of the transaction =
support? Any limitations or inappropriate design decisions?

Juergen


-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Friday, March 28, 2003 7:43 PM
To: spr...@li...
Subject: [Springframework-developer] Transaction support


Hi Rod, everybody,

I've checked in the following major changes:

- JndiServices is now a static helper (used in DataSourceUtils, =
JmsTemplate, and the EJB access classes); ContextFactory is dissolved =
for the time being.

- SingleConnectionDataSource can now wrap the underlying single =
connection to suppress close calls (via a DynamicProxy), to be able to =
accept close() calls from non-SmartDataSource aware users like O/R =
mapping toolkits.

- introduced generic TransactionStatus for programmatic rollback etc.

- moved PlatformTransactionManager from the AOP package to the =
transaction package, and reworked it (now features a getTransaction =
method taking propagationBehavior and isolationLevel parameters and =
returning a TransactionStatus, and commit and rollback methods).

- moved propagation behavior and isolation level constants to =
PlatformTransactionManager, using the java.sql.Connection values for the =
latter and adding a "default" value.

- added TransactionTemplate+TransactionCallback analogous to =
JdbcTemplate, the callback getting the TransactionStatus for otpional =
programmatic control and returning a result object to be able to return =
an object to the original caller.

- reworked AOP's TxControl into TransactionControl that uses =
TransactionStatus.

- completed transaction exceptions, modelling =
HeuristicCompletionException with an outcome state instead of a =
dedicated hierarchy for these rather rare situations.

- introduced JtaServices helper class and JtaTransactionManager =
implementation in com.interface21.transaction.jta (no dedicated =
JtaTemplate, easily achievable via feeding a JtaTransactionManager to =
TransactionTemplate).

- introduced SingleConnectionTransactionManager in =
com.interface21.transaction.mock, a transaction manager for =
SingleConnectionDataSource, handling autoCommit state and =
commit/rollback of the single underlying connection (for testing =
purposes, and for being able to run server-oriented data access and =
business logic transactionally in a standalone application).

- introduced AbstractPlatformTransactionManager in =
com.interface21.transaction.support, allowing for easy implementation of =
PlatformTransactionManagers (handling existing transactions, =
programmatic rollback-only, non-transactional fallback, etc), used by =
both JtaTransactionManager and SingleConnectionTransactionManager.

- introduced TransactionCallbackWithoutResult in =
com.interface21.transaction.support, allowing for implementing a =
doInTransaction version without the need to return a (null) result.

Rod, please check the AOP transaction interceptor, I've not tested it =
beyond the test suite. I am aware that we might still need some tweaking =
of the transaction support in terms of design, but I like the current =
version, and I consider it a good basis. I hope you like the design =
changes, of course I'm open to any suggestions.

Finally, I have that there aren't any tests for the transaction package =
yet - they are forthcoming, promised! (repeat to myself: "test first" =
"test first" "test first"...)

Regards,
Juergen


DI J=FCrgen H=F6ller
Senior System Architect
__________________________________

werk3ATS - division systementwicklung
part of werk3AT internetmedien oeg

europaplatz 4
A - 4020 linz

t.  +43 (0) 732 71 65 29
f.  +43 (0) 732 71 65 29 3
jue...@we...
www.werk3at.com
__________________________________
werk3ATS - WIR ENTWICKELN ERFOLG



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer