RE: [Springframework-developer] Update

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

Hi Rod,

Regarding AOP and transaction management: I'm really eager to look at =
that stuff. I'm currently trying to settle on a transaction handling way =
for our applications here at werk3AT, and this isn't as straightforward =
as it should be.

Interestingly, I've come up with something very similar to a thing your =
proposed: A com.interface21.jta package providing a JtaServices class =
and an associated TransactionCallback, among other things caring for the =
exception handling and transforming those awkward, loose JTA exceptions =
to the exception hierarchy in com.interface21.dao. We seem to duplicate =
effort here, so I guess we should try to synchronize. There's not much =
code involved, so I don't think that there has been much overhead yet.

Some sample application code using my current version:

public static void executeTransaction() {
	JtaServices.execute(
		new TransactionCallback() {
			public void doInTransaction() {
				executeTestUpdate();
				executeTestQuery();
			}
		}
	);
}

Obvious issues are:

- I use a JtaServices static helper class analogous to JndiServices =
rather than a JtaTemplate instance analogous to JdbcTemplate. The reason =
is that there's not much state involved currently: A thread only has one =
associated JTA UserTransaction, just like it only has one associated =
JNDI InitialContext - in constrast to potentially multiple JDBC =
DataSources. Does your implementation have more state that justifies =
using an instance, possibly configuration or potential subclassing?

- Instead of a new exception hierarchy in com.interface21.transaction, I =
chose to integrate the transaction exceptions into com.interface21.dao. =
The rationale behind this is that transactions are an inherent aspect of =
data access. Currently, I have only one new exception, namely =
DataAccessTransactionRollbackException. Other exceptions like JTA's =
SystemException get converted to the existing =
DataAccessResourceFailureException. The existing =
DeadlockLoserDataAccessException is now a subclass of =
DataAccessTransactionRollbackException.

- TransactionCallback.doInTransaction() does not throw any checked =
exceptions. Instead, any RuntimeException thrown causes the transaction =
to roll back (resp. a warning written to the log that the transaction =
should have been rolled back, when JTA isn't available), and gets =
rethrown to the caller. AOP allows for much more flexibility in this =
respect, but I don't see a more flexible way for the callback approach.

- A special characteristic of my version is that it allows for working =
without JTA as a fallback. If there's a problem retrieving the =
UserTransaction from JNDI and applying it, a warning gets written to the =
log, and the transactional application code gets executed without a =
transaction, using autocommit=3Dtrue. We currently use this for test =
suites that run in a plain VM with just a JNDI DataSource mock. It is =
also meant for being able to run your application in a non-JTA =
environment too (e.g. for a development or demo environment), while =
benefiting from JTA when available. BTW, an overloaded version of =
JtaServices.execute disables this fallback and enforces JTA =
availability.

- My current stuff may not be too sophisticated, but it works and I =
consider it beta quality. I have tested it with Tomcat 4.0/4.1 (both =
with and without Tyrex 0.9.7/1.0) and Resin 2.1, using Driver-backed =
"enabled" DataSources and real XADataSources. A version of Spring's JTA =
stuff can and should definitely make it for 0.9, as I consider =
transaction handling a very important issue.

- Note that at werk3AT, we don't need any distributed transactions yet: =
We simply use JTA for convenient transaction demarcation in high-level =
services. The underlying lower-level data access services use either =
JDBC via a JNDI datasource or the O/R mapping toolkit Hibernate (with a =
JNDI datasource underneath). This works nicely if the JNDI datasource is =
XA-capable, and allows for clear separation of concerns. Of course, =
one-phase commit is enough for this, so I don't mind "enabled" =
DataSources that are not truly XA-capable (like MySQL's). An obvious =
benefit of still basing our applications' transaction handling on JTA is =
that extending them to more datasources is very smooth.

- I've recently reviewed Hibernate's JTA usage in detail, i.e. in its =
source code. It's very straightforward, the only major issue is managing =
cache state. Hibernate needs to register a synchronization with the =
container's transaction manager, to be able to update the cache on =
transaction commit or rollback accordingly. Unfortunately, the JNDI =
location of the transaction manager is unspecified in J2EE, so Hibernate =
has a lookup interface and implementations for various application =
serves. In the current Hibernate version, this only works with explicit =
transaction handling in the data access code, and configuring Hibernate =
for JTA. Hibernate transactions then simply take part in existing JTA =
transactions, or start new ones if necessary. In the autocommit case, =
Hibernate cannot guarantee correct cache state, as there's no JTA =
synchronization then. This will be addressed by a JCA adapter in =
Hibernate 2.1.

- Finally, regarding PlatformTransactionManager: What functionality does =
this interface address in detail? Do we need to synchronize anything? =
Any concrete use cases?

So, how should we proceed? I could check in my current stuff, so that =
you can review it and merge it with your version. Of course, we can =
proceed the other way round too. What do you prefer?

Regards,
Juergen


P.S.:
Orion 2.0 has just been released. Hurray, it isn't dead! ;-) Seriously, =
I will definitely look at it soon. Hopefully, the web stuff is fully =
Servlet 2.3 compliant now.


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]
> Sent: Thursday, March 20, 2003 1:17 AM
> To: spr...@li...
> Subject: [Springframework-developer] Update
>=20
>=20
> Hi Guys,
>=20
> In case you're wondering why I've been silent lately I've
> been offline while my 18-month old son has been in hospital=20
> for heart surgery.  He's now recovering well after a bit of a=20
> scare last weekend.
>=20
> In the meantime I've been doing some work on Spring. I've
> continued to make some enhancements to the=20
> AbstractBeanFactory, which I'll commit early next week.
>=20
> AOP
>=20
> I've also reimplemented the AOP packages, and am very pleased
> with the results. (Developed test first, naturally, with 94%=20
> test coverage.) I'll also check this in in a few days. It=20
> builds on the new FactoryBean support, and I think is mature=20
> enough to make 0.9, if not 0.8 (depending on when we do the=20
> releases). The core AOP framework package is surprisingly=20
> simple: there's probably less code in it than the JDBC stuff.
>=20
> So please don't bother looking at the old AOP package...the
> new packages use the same concepts, but I think are a=20
> significant improvement.
>=20
>=20
> TRANSACTION MANAGEMENT
>=20
> Following a suggestion from Yann that reminded me of my
> original plans, I'm looking at trying to do for JTA what=20
> Spring does for JDBC: simplifying API using callbacks, and a=20
> meaningful hierarchy of runtime exceptions. One of the=20
> reasons JTA is a pain to use is that not only are all=20
> exceptions checked, there's no common superclass so they all=20
> need to be caught individually.
>=20
> I'm planning a new com.interface21.transaction package
> analogous to the com.interface21.dao package defining the=20
> exception hierarchy. A com.interface21.jta package (which I=20
> originally had but dropped for the first Spring release) will=20
> contain a JTA counterpart of the JdbcTemplate, using a=20
> similar calllback approach. Not sure whether this will make=20
> 1.0 or any interim release.
>=20
> An AOP transaction interceptor will offer CMT via AOP,
> building on this common tx infrastructure. I'll be checking=20
> in an experimental version of this next week. I think AOP has=20
> the potential to do much more powerful CMT than EJB. For=20
> example, it's possible to specify which checked exceptions=20
> should cause automatic rollback. This is impossible with EJB.=20
> Also, different transaction interceptors could be used for=20
> each target platform: e.g. Tomcat/Tyrex, Orion, WebLogic or=20
> JBoss. This would ensure that application code was truly portable.
>=20
>=20
> VOLUNTEERS WANTED
>=20
> I've designed a generic TransactionInterceptor that uses a
> PlatformTransactionManager interface that plugs into a=20
> potentially server-specific tx mgt API. (There are things to=20
> do with isolation levels etc. for which it's good to be able=20
> to use proprietary extensions.) I'm planning to do a=20
> JTA-based portable implementation, but I'd love volunteers to=20
> write PlatformTransactionManager implementations that could=20
> be used with particular servers, such as
> - JBoss
> - Tomcat/Tyrex
> - WebLogic
> - Orion
>=20
> I think it will also be important to have sample apps testing
> and demonstrating this functionality. I think it's going to=20
> be tremendously powerful, yet easy to use.
>=20
> Regards,
> Rod
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Does your code think in ink?
> You could win a Tablet PC. Get a free Tablet PC hat just for playing.=20
> What are you waiting for?=20
> http://ads.sourceforge.net/cgi-> bin/redirect.pl?micr5043en
>=20
>=20
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20