[seam-dev] Persistence Module Overview

Mon Oct 18 11:02:37 EDT 2010

EE6 didn't affect when a UT must be available. I know Stuart has some abstraction for this, but it sounds like it needs to be more pluggable or sth.

On 17 Oct 2010, at 13:48, Denis Forveille wrote:

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