Re: [Springframework-developer] Update

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

To prove I really am practising test first development these days, the test
coverage on the aop.framework package is 95%. I am very keen that the
overall test coverage should increase over time: it seems to be falling
marginally.

I'm still working on the aop.interceptor.transaction package, which was
based on old code, so it will have comprehensive tests in a few days.

Regards,
Rod

----- Original Message -----
From: "Rod Johnson" <rod...@in...>
To: "jürgen höller [werk3AT]" <jue...@we...>;
<spr...@li...>
Sent: Sunday, March 23, 2003 12:40 AM
Subject: Re: [Springframework-developer] Update


> 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
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:Crypto Challenge is now open!
> Get cracking and register here for some mind boggling fun and
> the chance of winning an Apple iPod:
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer