aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giuseppe Gerla <>
Subject Re: Design for Aries transaction blueprint 2.0.0
Date Sat, 11 Jul 2015 07:37:25 GMT
it sounds good for me.



2015-07-10 9:24 GMT+02:00 Christian Schneider <>:

> I would like to do a redesign of Aries transaction blueprint to make it
> simpler and faster.
> Currently Aries transaction blueprint is designed around bundle and method
> patterns for transactions.
> They work like:
> method="*", type=Supported
> method="myMethod", type=Required
> These patterns are recorded for individual beans as well as for bundles.
> Some time ago Annotation support was added to this. So the patterns above
> are created from Annotations too now. As a last step JTA 1.2 transactions
> were added
> as another source.
> These variants made the code quite big and complicated. For example look
> into TxComponentMetaDataHelperImpl.getComponentMethodTxAttribute and follow
> the code it uses to determine which transaction type to use at runtime. In
> addition to the complexity this is also not very fast.
> I would like to clean up this for a new 2.0.0 version. The idea is quite
> simple.
> We only support JTA 1.2 @Transactional annotations. According to JTA rules
> they can be placed on classes and methods and the typical inheritance and
> overriding rules are applied.
> As even just this can be a bit complex at runtime I would like to do all
> the parsing and overriding at context startup and create a simple structure
> for runtime usage like this:
> Map<Method, TxType> beanTransactionData;
> So at runtime we create one interceptor per bean and store the
> beanTransactionData in it. It then just needs to lookup the method and
> directly knows the transaction type to use.
> I would also like to change the xsd to only support tx:enable-annotations.
> So transaction blueprint would be in line with Aries JPA 2 which also only
> allows EntityManager injection using standard JPA annotations.
> I would also like to discuss a another change to support coordinations
> without transactions. I will write a separate mail for this.
> Christian
> --
> Christian Schneider
> Open Source Architect

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message