On 30 nov. 2011, at 00:48, Linda DeMichiel wrote:
>>> Just to be very clear.... What are you referring to by "container level
>>> method
>>> invocation call"? The call to the entity manager proxy?
>>
>> Not the call to the entity manager proxy. I mean the code that is calling the entity manager proxy (e.g. a session bean
>> calling the entity manager proxy.)
>>
>> Perhaps a clearer proposal could be:
>>
>> "
>> If the entity manager is invoked outside the scope of a transaction, any entities loaded from the database will
>> immediately become detached at the end of the container level method invocation call (e.g. when the session bean method
>> ends).
>> "
>
> Ah, thanks. That is not the intended semantics. Rather it is that the
> persistence context is created to service the method call that is made
> on the entity manager only. It doesn't have the duration of a business
> method invocation.
Is it really?
I have to admit I am amongst people that read this as bound to the duration of the business method call. The main problem with this approach is that many em.find() calls are essentially useless as they would not load (lazy) associations.
Upon detachment, the provider then raises a NotLoadedException of some sort. The only way to work around that is to write a query with the specific fetch pattern that ought to be used.
If entities are detached after the business call, the user can navigate and use PersistenceUtil contracts to load the appropriate part of the graph before ending the method.
Note that for a PC that detaches entities upon EM method calls, Hibernate has a specific API with specialized contracts to tailor that kind of use case. I don't think our existing EM API is necessarily well suited for that per se.
Emmanuel