[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openejb-user
Subject:    Re: Fetch without transaction
From:       José_Luis_Cetina <maxtorzito () gmail ! com>
Date:       2013-10-30 16:32:08
Message-ID: CAPyf0gegWEe2iYz1Y5YTX3TuXAoZMhoDqfBCF=csHxXSA8iW8Q () mail ! gmail ! com
[Download RAW message or body]


In resume, then i need always a transaction in my own method or in the
client that invokes any method that need to fetch any other entity.


2013/10/30 José Luis Cetina <maxtorzito@gmail.com>

> Ok
>
>
> 2013/10/30 Romain Manni-Bucau <rmannibucau@gmail.com>
>
>> shouldn't work with BEAN exepted if called from a bean which started a tx
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2013/10/30 José Luis Cetina <maxtorzito@gmail.com>:
>> > Is injected @PersistenceContex
>> >
>> >
>> > @Stateless
>> > @TransactionAttribute(TransactionAttributeType.REQUIRED)
>> > @TransactionManagement(TransactionManagementType.CONTAINER)
>> > public class MenusFacade implements MenusFacadeLocal {
>> >
>> >     @PersistenceContext(unitName =
>> > BusinessLayerUtils.KX_GLOBAL_PERSISTENCE_UNIT_NAME)
>> >     private EntityManager em;
>> > ............
>> >
>> >
>> > 2013/10/30 Romain Manni-Bucau <rmannibucau@gmail.com>
>> >
>> >> Hi
>> >>
>> >> is your entity manager created manually or managed?
>> >> Romain Manni-Bucau
>> >> Twitter: @rmannibucau
>> >> Blog: http://rmannibucau.wordpress.com/
>> >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> >> Github: https://github.com/rmannibucau
>> >>
>> >>
>> >>
>> >> 2013/10/30 José Luis Cetina <maxtorzito@gmail.com>:
>> >> > From http://docs.oracle.com/javaee/6/tutorial/doc/bncij.html
>> >> >
>> >> > Supports Attribute
>> >> >
>> >> > If the client is running within a transaction and invokes the
>> enterprise
>> >> > bean’s method, the method executes within the client’s transaction.
>> If
>> >> the
>> >> > client is not associated with a transaction, the container does not
>> >> start a
>> >> > new transaction before running the method.
>> >> >
>> >> > Because the transactional behavior of the method may vary, you
>> should use
>> >> > the Supports attribute with caution.
>> >> >
>> >> >
>> >> > The problem is that im calling my ejb directly from my managedbean
>> >> (@named)
>> >> > and of course the "client" doesn't have any transaction and the
>> behavior
>> >> is
>> >> > the same, i could not fecth using eager, fetch
>> >> > or getFetchPlan().addFetchGroup() any of this work with SUPPORTS.
>> >> >
>> >> >
>> >> > Then as i can see the only way is to use REQUIRED, because i use
>> >> stateless,
>> >> > but this let me thinking, why this work
>> >> > with @TransactionManagement(TransactionManagementType.BEAN)? , with
>> Bean
>> >> > transaction i don't have to star any transaction for use a fetch
>> >> >
>> >> >
>> >> > 2013/10/30 Jean-Louis MONTEIRO <jeanouii@gmail.com>
>> >> >
>> >> >> oups, message sent too quickly ...
>> >> >>
>> >> >> SUPPORTS is usually fine as a default for "finder" methods.
>> >> >> As soon as there is no transaction, an entity is detached when
>> returned
>> >> by
>> >> >> the entity manager.
>> >> >> Even with SUPPORTS btw
>> >> >>
>> >> >> When REQUIRED (or any transaction) is used, the entity remains
>> attached
>> >> and
>> >> >> managed my the persistence context till the end of the transaction
>> by
>> >> >> default.
>> >> >>
>> >> >> For an EPC in a Stateful, it's a bit different.
>> >> >> So I'd say you have the desired behavior as per the spec.
>> >> >>
>> >> >> JLouis
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2013/10/30 Jean-Louis MONTEIRO <jeanouii@gmail.com>
>> >> >>
>> >> >> > SUPPORTS is fine then
>> >> >> >
>> >> >> >
>> >> >> > 2013/10/30 José Luis Cetina <maxtorzito@gmail.com>
>> >> >> >
>> >> >> >> Sorry if i post here, i posted this some days ago, but in openjpa
>> >> >> mailing
>> >> >> >> list somethings you dont get answer's, i hope somebody can help.
>> >> >> >>
>> >> >> >>
>> >> >> >> Hi, i have a problem, im changing my ejbs from
>> >> >> >>
>> >> >> >> @TransactionManagement(TransactionManagementType.BEAN)
>> >> >> >>
>> >> >> >> to
>> >> >> >>
>> >> >> >> @TransactionAttribute(TransactionAttributeType.REQUIRED)
>> >> >> >> @TransactionManagement(TransactionManagementType.CONTAINER)
>> >> >> >>
>> >> >> >> My ejb methods that only performs read only querys are marked
>> with
>> >> >> >> @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
>> because
>> >> >> they
>> >> >> >> are read only, this works as expected. But when i try to fetch
>> some
>> >> >> >> properties from my entity that is marked as LAZY i could never
>> >> retrieved
>> >> >> >> because is null. If i mark my entity property (list) with EAGER
>> or
>> >> if i
>> >> >> >> mark my method with
>> >> >> >> @TransactionAttribute(TransactionAttributeType.REQUIRED) all
>> works.
>> >> >> >>
>> >> >> >> So my question is, do i have to use a transaction for read only
>> >> querys
>> >> >> >> that
>> >> >> >> need any kind of fetch, if yes, Why???
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Jean-Louis
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Jean-Louis
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > -------------------------------------------------------------------
>> >> > *SCJA. José Luis Cetina*
>> >> > -------------------------------------------------------------------
>> >>
>> >
>> >
>> >
>> > --
>> > -------------------------------------------------------------------
>> > *SCJA. José Luis Cetina*
>> > -------------------------------------------------------------------
>>
>
>
>
> --
> -------------------------------------------------------------------
> *SCJA. José Luis Cetina*
> -------------------------------------------------------------------
>



-- 
-------------------------------------------------------------------
*SCJA. José Luis Cetina*
-------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]