[seam-dev] Persistence Module Overview

[Stuart Douglas]

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 at redhat.com> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>