Re: [Springframework-developer] Update

[Rod J. <rod...@in...>]

All,

I've now checked in my new AOP framework (com.interface21.aop.framework),
and the accompanying tests. The org.aopalliance packages (binaries included
in /lib directory) are the APIs currently agreed by myself, Jon Tirsen
(Nanning Aspects) and Bob Lee (jAdvise) for interoperability. The metadata
attribute implementation is pluggable, but I'm planning to use Attrib4j
(Sourceforge) and have been in touch with Mark Pollack, the author, who's
keen to help it meet our requirements.

NB: The old AOP packages are gone: everyone please make sure they don't have
the old sources hanging around.

I've also checked in a com.interface21.aop.interceptor.transaction package
containing a generic CMT interceptor. The PlatformTransactionManager is in
this package: let me know if there are any problems in the design of this
interface.


Juergen,

We're on the same track with the JTA callback approach you've suggested, so
we should pool our efforts.

My thoughts:

- I don't like statics. For example, it's impossible to use a test subclass
overriding methods to check usage. So I'd prefer that it was a true object,
even if there's no state at this point. After all, the cost of tx management
is far greater than the cost of creating and destroying a small object.
Also, I think some state may come in (see below). For example, your "allow
no JTA" could be a bean property.
- My proposed callback interface (which I hadn't implemented yet) returned a
boolean, indicating whether the tx should be committed or rollback. I'm not
sure whether this is better 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 like? My AOP
transaction interceptor has a TxControl class that allows this. Maybe this
class could be refactored into the common package. This could be an
alternative to the boolean return for enforcing rollback. I'm not sure which
approach would be the best.
- I don't much like sharing the dao exceptions. I've checked in the
com.interface21.transaction package which contains my unchecked tx exception
hierarchy, which my tx interceptor uses. I'd prefer to standardize on this.

I think the biggest questions are:

- Do we want to try to refactor so that the new jta package shares the
TransactionControl and PlatformTransactionServices implementation from my
AOP transaction interceptor package? This would mean that the callback
wasn't JTA-specific, but could work with any PlatformTransactionManager
implementation. The common functionality would be in the
com.interface21.transaction package and multiple PlatformTransactionManager
implementations could be in packages such as
com.interface21.transaction.jta/wls/jboss etc.
- Is my PlatformTransactionManager interface adequate for this goal or for
how I'm trying to use it in the AOP stuff.

Ideally it would be good if we pooled our efforts on a really good low-level
tx infrastructure, leaving the AOP interceptor as just a thin layer over
that.

I think there's probably a bit more discussion to have before you check in
your callback mechanism.

Regards,
Rod

----- Original Message -----
From: "jürgen höller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, March 20, 2003 8:49 AM
Subject: RE: [Springframework-developer] Update


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


-------------------------------------------------------
This SF.net email is sponsored by: Tablet PC.
Does your code think in ink? You could win a Tablet PC.
Get a free Tablet PC hat just for playing. What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer