In case anyone else is trying the same thing...reposting emails from ejb3-feedback@sun.com

After calling the stateless session bean method to fill in more
details in the object, the parameters to the stateless session bean
(fresh from the client tier) will be in the detached state. So you'll
want to invoke EntityManager.merge() on them, and then use the
objects returned from the merge() call to perform the relationship
traversal:

public Order populateLineItems(Order order) {
order = em.merge(order);
order.getLineItems();
return order;
}


This isn't exactly what the extended persistence context was designed
for; extended persistence context comes into play if you were using a
stateFUL session bean, and basically allows (in its current
incarnation) the EntityManager's working set of objects (the
"persistence context", loosely) to remain in the managed state for
the duration of the stateful session bean's lifecycle. Depending on
your isolation level desires, this might be a direction you'd want to
go in, or the stateless / merge approach might fit your needs. But
the instance that you brought out of your physical tier would still
be detached, so you'd still need the merge() semantics in the sfsb
approach.

-Patrick

On May 2, 2005, at 8:44 PM, Redmond, Ana wrote:

> It is fine that the db access only happens in the tier that uses the
> entity manager.
>
> What I want to do is -
> Get the initial object...send it to client tier.
> User may want to see more details now.
> Client asks the stateless session bean to load the field it didn't
> fetch initially, providing it the object - lazy fetching
> Stateless session bean returns back the object with the lazy fetched
> field loaded. Now the client can use the lazy loaded properties.
>
> It is an optimization (useful one) to not have to load all the
> information before-hand, mostly for OneToMany or ManyToMany
> properties.
>
> I don't need to access the db from other tiers, in fact, would prefer
> not to. That would break the layer separation.
>
> But, I would like to be able to load the lazy fetched information with
> something like...
> entityManager.fetch(beanObjectWithSomePropertyNotFetched,
> propertyToFetch)
> This happens inside a second transaction at a later time. And
> results in
> the lazy loaded property populated.
>
> Hope this makes sense. Does 'Extended Persistence Context' handle this
> scenario? -Ana
>
>
>
> -----Original Message-----
> From: Patrick Linskey []
> Sent: Monday, May 02, 2005 5:22 PM
> To: Gavin King
> Cc: Redmond, Ana; ejb3-feedback@sun.com
> Subject: Re: Lazy fetching from Beans
>
>
> On May 2, 2005, at 8:16 PM, Gavin King wrote:
>
>
>> However, we are in the process of introducing a new feature called
>> "Extended Persistence Context" that solves this problem and means you
>> can have associations fetched even after the initial transaction ends
>>
>
> Just to be clear, the upcoming extended persistence context will allow
> objects to remain managed outside of a transaction, but if you are
> serializing your instances across the wire to another machine, the
> instances will still be detached in the remote tier in typical usage
> (extended or otherwise).
>
> The rule of thumb is that lazy loading (and any direct database access
> at all, really) can only happen in the physical tier that uses the
> EntityManager.
>
> -Patrick
>
> --
> Patrick Linskey
> SolarMetric Inc.
>