[seam-dev] Persistence Module Overview

[Denis Forveille]

  Stuart,

I don't know if these issue is part of the "Persistence Module" or not, but what IMHO is important is that Seam 3 plays nicely with 
the "User Transaction" (UT) and the JNDI space where the UT is looked up.

The JEE 5 specification defines usually when and where the JNDI namespace for UT is available or not. For example, there is no 
guarantee to have access to a viable JNDI space and so to get a UT in session listeners or in "secondary" threads like the one 
started by quartz for example.

In Seam 2 (but also in other frameworks that abstract those objects) there are lots of "workarounds" or "empty catch blocks" to 
handle the situation. I have now in mind  the code  added (I commit some) to address the case of session listeners that tries to 
perform a lookup for UT and play (ie commit/rollback) with it when a session closes. JEE 5 does not guarantee that such objects are 
available in such contexts.

This has always been a problem with AS that (more) strictly enforce this, like WebSphere v6.x and WebSphere 7.

I know that JNDI specs changed in JEE6 (but not JTA) but I don't know if things changed regarding the availability of a JNDI name 
space "everywhere" and also to have acces to a valid "UT" "everywhere", or at least in any place Seam will need it.

I don't know if there are "easy" solutions for this problem but at least this should be adress as nicely as possible, and I hope JEE 
6 solved some of those problems.

When the persistence module and Seam 3 will be available in some "testable" state, I'll test them on WebSphere 8 (still in beta for 
now).

Denis.

On 10/14/2010 08:44 PM, Stuart Douglas wrote:
> On Fri, Oct 15, 2010 at 11:17 AM, Stuart Douglas
> <stuart.w.douglas at gmail.com>  wrote:
>> 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
> That should be bean level, not field level.
>
> Stuart
>
>> 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
>>>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev