[weld-dev] persistence and transactions outside Java EE

[Gavin King]

Funny, as far as I know, no other user ever complained about this.

REQUIRES_NEW has a couple of legitimate usecases, but they're very,
very rare. I have never met a usecase for NOT_SUPPORTED.

You must have some very strange requirements if that was one of your
"main issues" with Seam 2.x. I could probably think up about 100 more
serious problems/limitations of Seam.

On Tue, Nov 24, 2009 at 4:21 PM, Arbi Sookazian <asookazian at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org