RE: [Springframework-developer] Transaction support

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

Rod,

I guess removing the check in TransactionInterceptor and modifying the =
test case accordingly will solve the issue.

Now that we seem to approach a certain degree of stability in terms of =
transaction support too, we should actively consider releasing 0.8. =
We're not really following "release early, release often" up to now...

A combined developer download will be enough for the moment, I assume, =
we don't really need a binary-only download before 1.0. Have you looked =
at how SourceForge's release support works already? It shouldn't be hard =
to figure out.

Even for 0.8, we should try to raise some attention just after the =
release, for example at TheServerSide. We could gain important feedback, =
long enough before 1.0 to be able to still tweak the design if =
necessary.

Juergen


-----Original Message-----
From: Rod Johnson [mailto:rod...@in...]
Sent: Thursday, April 03, 2003 2:27 PM
To: j=FCrgen h=F6ller [werk3AT];
spr...@li...
Subject: Re: [Springframework-developer] Transaction support


Juergen,

I needed to put that check in to get the tests to pass. However, the
clarification about how PlatformTransactionManager implementations =
should
behave would also resolve the problem (meaning I could modify the test =
case,
not the class).

I haven't looked at your code in great detail, but from what I've seen =
it
looks good and I endorse the design.

Regards,
Rod


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.

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