[weld-dev] persistence and transactions outside Java EE

[Arbi Sookazian]

One of the main issues I had with Seam 2.x was the (lack of) tx propagation
support options (specifically REQUIRES_NEW and NOT_SUPPORTED) when using
@Transactional when compared with EJB3 tx support and Spring tx support.

Refer to this thread:
http://sfwk.org/Community/TransactionalPropagationTypes

and this: https://jira.jboss.org/jira/browse/JBSEAM-595

and this: https://jira.jboss.org/jira/browse/JBSEAM-4391

AFAIK this is not fixed and/or released.  Will this be fixed and released
with Seam3?


On Tue, Nov 24, 2009 at 12:44 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

> Btw, this is exactly why most people use Seam 2. They don't want to deal
> with EJB. They can just annotate with @Name and inject a Seam-managed
> persistence context. The transactions are hooked into whatever they want:
> local, JTA or Spring. It's "the hell with EJB" approach.
>
> I'm just saying perhaps we can find a way to cater to this approach in Java
> EE so we don't lose those people to the platform.
>
> -Dan
>
>
> On Tue, Nov 24, 2009 at 3:41 PM, Dan Allen <dan.j.allen at gmail.com> wrote:
>
>>
>>
>>> It's somewhat related....in terms of Resin, we actually don't have such
>>> a thing as a traditional EJB container - we have "aspects" such as
>>> transactions delivered via meta-data (e.g. @TransactionAttribute), the
>>> aspects are bound to an underlying implementation (e.g. transaction
>>> manager) and can be used in any component model including managed beans
>>> or EJB. The "EJB Lite" distinction is tenuous since you don't really
>>> need to use the EJB component model per se.
>>
>>
>> To be honest, I'm kind of confused myself now. Circling back to my initial
>> argument, the two options we provide in Java EE at this moment are:
>>
>> - a non-transactional "simple" managed bean or,
>> - an EJB session bean (which is, by default, transactional, and more)
>>
>> So if the developer wants a transactional bean without using an EJB
>> container, they have to use some sort of framework (or portable CDI
>> extension) to get it. To me, that is where Java EE falls apart. There needs
>> to be some middle of the road that the developer can get a transactional
>> bean out of the box OR we just need to say, if you want a transactional
>> bean, you have to use EJB w/ at least EJB lite, period.
>>
>> Why isn't the "simple" transactional bean something that Java EE can
>> provide. Clearly a use case is being ignored.
>>
>> -Dan
>>
>> p.s. The "simple" transactional bean would be a bean w/
>> @TransactionAttribute and somehow @PersistenceContext would be supported on
>> the bean.
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>> Registered Linux User #231597
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>> http://www.google.com/profiles/dan.j.allen
>>
>
>
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091124/d411d8c7/attachment-0001.html