Re: [seam-dev] Persistence Module Overview

That is a good question. Currently the CDI specification does not allow interceptors on the methods level to override interceptors on the field level (I have

filed an issue for this), if @Transactional was an interceptor binding it would not be possible to override the behaviour of individual methods. Also it is not really desirable to make @TransactionAttribute an interceptor binding, and I think we should prefer @TransactionAttribute where possible, just so there is only one annotation users need to remember. Good point about the stereotype's though. I might add some trickery to the transaction extension to deal with this. Stuart On Fri, Oct 15, 2010 at 10:56 AM, Shane Bryzak <sbryzak(a)redhat.com&gt; wrote: >  Great work, thanks Stuart. > > I was wondering about one thing though - why is @Transactional not an > interceptor binding?  The way it is now, you can't use it in a stereotype > (though you can probably use @TransactionalInterceptorBinding, but this is > in the impl module not the api, and having to use it instead of > @Transactional seems inconsistent). > > Shane > > On 15/10/10 09:05, Stuart Douglas wrote: >> >> I just though I would send out a quick overview of exactly what is in >> the persistence module at the moment: >> >> >> Transactions: >> >> It provides a SeamUserTransaction object that extends the JTA >> UserTransaction (this means a dependency on the jta API). >> >> Three default implementations will be provided >> - The default EE version that either looks up UserTransaction in JNDI >> or retrieves it from the EJBContext if a CMT is active >> - An implementation that uses EntityTransaction, this is retrieved from >> the SMPC >> - An implementation that uses hibernate's transaction API (to be done) >> >> It does not use the CDI's ability to inject the UserTransaction for a >> number of reason: >> - It is not available in all environments >> - It is not available in EJB's that use CMT >> >> It provides a transaction interceptor, this allows you to use >> @TransactionAttribute on managed beans the same way you would on >> EJB's. >> It provides @Transactional and @SeamApplicationException for >> environments where these API's are not available. >> >> Managed Persistence Contexts >> >> - Defined as follows: >> >> @SeamManaged >> @Produces >> @ConversationScoped >> @PersistenceUnit("myPu") >> EntityManagerFactory enf; >> >> - This will work even in environments where @PersistenceUnit injection >> is not directly supported, as seam-persistence will bootstrap it for >> you. >> >> - The SMPC provides the following: >> - Automatic transaction enlistment >> - Ability to use EL in queries >> - Automatic hibernate search integration, if available >> - Ability to set manual flush mode if required >> - Event is fired when the SMPC is created, to allow for additional >> configuration such as adding hibernate filters. >> >> It also provides @TransactionScoped for transaction scoped beans >> (forgot to put this in the reference guide, oops) >> >> There are currently tests for jboss-as, jetty, and jetty+openjpa (with >> no hibernate classes present on the classpath). I am planning on also >> adding glassfish, glassfish+hibernate, and probably a few more as >> well. >> >> I have also added seam managed transactions to the faces module, this >> is similar to seam 2, however it has two notable improvements: >> - It can be controlled on per view basis (including using wildcards) >> - it can be enabled only for the RENDER_RESPONSE, so you have manual >> transaction control in your business logic, and then seam opens a >> transaction for you when rendering to prevent LIE's (this also can be >> configured on a per view basis). >> >> I think that just about covers it. If anyone has any questions or >> comments fire away. >> >> Stuart >> _______________________________________________ >> seam-dev mailing list >> seam-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/seam-dev > >