RE: [Springframework-developer] Update

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

Hi Rod,

I've just had a look at your AOP transaction support and the =
PlatformTransactionManager. BTW, I agree that a true JtaTemplate object =
makes sense, as there already is more than one property. And your =
separate transaction exception hierarchy is fine too, although it =
currently lacks a TransactionSystemException matching JTA's general =
SystemException.

Now, some thoughts on the current state:

- First of all, I suggested to change JndiServices into a static helper =
class a while ago. I really don't see much value in JndiServices being a =
true object, as I've already stated. JndiServices effectively just =
simplifies context closing, there isn't great potential for extending =
it. For example, DataSourceUtils is a static helper too, and it uses =
resp. should use JndiServices... I don't mind true objects of course, =
it's just that we need a consistent approach to decide between static =
helper utils and true objects.

- Apropos consistency: I've currently got a JtaServices class that offer =
static helpers for easy JTA access and implicit exception translation. =
Furthermore, there's a JtaTemplate class analogous to JdbcTemplate that =
allows for transactional execution via a callback. It uses JtaServices =
internally. If JndiServices were a static helper too, then we could say =
that XXXUtils and XXXServices were indicating static helpers while =
XXXTemplate were true objects. Or should we adopt a different strategy?

- Regarding PlatformTransactionManager: While the concept is obvious, =
I'm not entirely convinced whether it will ever be used beyond a JTA =
implementation. How exactly do those container-specific things like =
isolation level handling work? I assume they all use JTA, with some =
specific tweaks. Generally, could there be a viable =
PlatformTransactionManager that does not use JTA, especially for AOP? A =
JDBC-connection-based one will not work - the (non-JTA) datasource isn't =
even fetched from JNDI when the method call gets intercepted, and it's =
already returned to the pool on method call end. To me, it seems that =
one needs to use JTA anyway for high-level transaction management =
outside of the low-level resource-handling code. In this case, the =
PlatformTransactionManager might abstract too much - it could assume JTA =
and offer hooks for server-specific tweaking.

- A special issue: transaction propagation. We should support taking =
part in transactions that already exist at interception/callback time, =
no matter whether from Spring or direct JTA transaction handling. =
Currently, JtaTemplate achieves this by explicitly checking for an =
existing transaction and suppressing commit resp. just setting =
rollback-only accordingly. More concretely, it has three propagation =
behavior strategies: "support existing" (do not create new one), "create =
new if not existing" (default), "create new always" (nesting -> not =
supported by most JTA implementations).

- Concerning a common transaction infrastructure: Yep, absolutely - we =
need a common approach. And it needs to be simple and easy to grasp, =
else we don't gain much in comparison to direct JTA. So JtaTemplate =
should be based on the same low-level code as TransactionInterceptor. =
This could be my current JtaServices, your PlatformTransactionManager, =
or a JTA-based cousin of it. To avoid duplicated work, I will stop =
working on JtaTemplate until we have settled on a certain approach.

Regards,
Juergen


> -----Original Message-----
> From: Rod Johnson [mailto:rod...@in...]=20
> Sent: Sunday, March 23, 2003 1:41 AM
> To: j=FCrgen h=F6ller [werk3AT];=20
> spr...@li...
> Subject: Re: [Springframework-developer] Update
>=20
>=20
> All,
>=20
> I've now checked in my new AOP framework=20
> (com.interface21.aop.framework), and the accompanying tests.=20
> The org.aopalliance packages (binaries included in /lib=20
> directory) are the APIs currently agreed by myself, Jon=20
> Tirsen (Nanning Aspects) and Bob Lee (jAdvise) for=20
> interoperability. The metadata attribute implementation is=20
> pluggable, but I'm planning to use Attrib4j
> (Sourceforge) and have been in touch with Mark Pollack, the=20
> author, who's keen to help it meet our requirements.
>=20
> NB: The old AOP packages are gone: everyone please make sure=20
> they don't have the old sources hanging around.
>=20
> I've also checked in a=20
> com.interface21.aop.interceptor.transaction package=20
> containing a generic CMT interceptor. The=20
> PlatformTransactionManager is in this package: let me know if=20
> there are any problems in the design of this interface.
>=20
>=20
> Juergen,
>=20
> We're on the same track with the JTA callback approach you've=20
> suggested, so we should pool our efforts.
>=20
> My thoughts:
>=20
> - I don't like statics. For example, it's impossible to use a=20
> test subclass overriding methods to check usage. So I'd=20
> prefer that it was a true object, even if there's no state at=20
> this point. After all, the cost of tx management is far=20
> greater than the cost of creating and destroying a small=20
> object. Also, I think some state may come in (see below). For=20
> example, your "allow no JTA" could be a bean property.
> - My proposed callback interface (which I hadn't implemented=20
> yet) returned a boolean, indicating whether the tx should be=20
> committed or rollback. I'm not sure whether this is better=20
> than void, as it makes the interface slightly harder to implement.
> - I agree with your approach to exceptions and rollback.
> - Do you intend to allow a setRollbackOnly mechanism or the=20
> like? My AOP transaction interceptor has a TxControl class=20
> that allows this. Maybe this class could be refactored into=20
> the common package. This could be an alternative to the=20
> boolean return for enforcing rollback. I'm not sure which=20
> approach would be the best.
> - I don't much like sharing the dao exceptions. I've checked=20
> in the com.interface21.transaction package which contains my=20
> unchecked tx exception hierarchy, which my tx interceptor=20
> uses. I'd prefer to standardize on this.
>=20
> I think the biggest questions are:
>=20
> - Do we want to try to refactor so that the new jta package=20
> shares the TransactionControl and PlatformTransactionServices=20
> implementation from my AOP transaction interceptor package?=20
> This would mean that the callback wasn't JTA-specific, but=20
> could work with any PlatformTransactionManager=20
> implementation. The common functionality would be in the=20
> com.interface21.transaction package and multiple=20
> PlatformTransactionManager implementations could be in=20
> packages such as com.interface21.transaction.jta/wls/jboss etc.
> - Is my PlatformTransactionManager interface adequate for=20
> this goal or for how I'm trying to use it in the AOP stuff.
>=20
> Ideally it would be good if we pooled our efforts on a really=20
> good low-level tx infrastructure, leaving the AOP interceptor=20
> as just a thin layer over that.
>=20
> I think there's probably a bit more discussion to have before=20
> you check in your callback mechanism.
>=20
> Regards,
> Rod