Another way to achieve this is to use different fetch plans for
different use cases, which will result in the right stuff being
detached in each context.

You would still need to manually tune what gets detached, of course.

> And i'm kinda unwilling to inject EntityManager into those top-level
> classes.

Note that in your proposal, an EntityManager of some sort is still
around; you just don't have access to it. Also, note that my proposal
did not suggest / require injecting an EntityManager into the
top-level classes.

-Patrick

On 9/12/07, Evgeny Shepelyuk <[EMAIL PROTECTED]> wrote:
> >> The idea is that Toplink JPA supports that feature. OpenJPA - no.
> >> Maybe this can be done as some configurable behaviour ?
> >
> > They do, but really, all that they are doing is hiding the open EM. In
> > other words, the objects are not actually really detached yet.
> >
> > What type of application are you building? Most server frameworks
> > these days have some sort of request boundary concept, such as a
> > ServletFilter; given such a concept, it's trivial to register an EM
> > with a ThreadLocal or some equivalent construct at the beginning of
> > the request, and close the EM when the context closes.
>
> It's not web application but rather some core service processing request
> coming into it by RMI, REST/HTTP and even SOAP :)
>
> Now we're in the middle of migration to JPA from custom ORM layer.
> And just wanna separate "business logic" classes from JPA stuff completely.
> We can easily avoid loading of field of detached entites writing smth like
> that
>
> OrderEntity order = .... ;// passed detached entity from some DAO
> UserEntity user = new UserDAO().get(order.getUserId());
>
> but i think more convenient way will be following :)
>
> OrderEntity order = .... ;// passed detached entity from some DAO
> UserEntity user = order.getUser();
>
> Problem is that for example i have one class that makes some DB operation
> and it's used from
> several internal clients. Those clients are asking for some entity, then
> ask for it's dependants etc.
> And i'm kinda unwilling to inject EntityManager into those top-level
> classes.
>
> --
> Best Regards
> Evgeny K. Shepelyuk
>


-- 
Patrick Linskey
202 669 5907

Reply via email to