7:48 a.m.
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(a)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(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev