Mario what's the best practice with Orchestra here? I mean do you think request scoped beans should be replaced by conversation scoped beans when Orchestra is around?
On Sat, Mar 29, 2008 at 7:23 PM, Bernhard Huemer <[EMAIL PROTECTED]> wrote: > Hello, > > I think that providing integration with the > OpenEntityManagerInViewFilter is much more preferable to adding another > managed scope. For example, think of a master-detail view at which the > user starts a new conversation by selecting one of the entries being > loaded via a PersistenceContext. Supposing Orchestra reuses the > PersistenceContext provided by the Filter? Wouldn't you be able to deal > with those "request-scoped entities" just like as if they had been > loaded within a conversation? > > regards, > Bernhard > > On 03/29/2008 +0100, > Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi! > >> In my app, there is an > >> org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter that > >> binds an entityManager to each request. > >> With Orchestra do I really have to remove this filter? > > No. Orchestra does not help with request scoped beans. Mixing OEMIVF > > with Orchestra should work I think. > > > >> For example I have a backing bean with request scope that lists > >> entities, removing this filter adding orchestra, it starts failing. > > Another solution might be to put your request scoped bean into a flash > > scope, though, you have to be aware that then it might be possible to > > not see fresh data from the database as the ORM PersistenceContext > > caches the data. If you change data this is something you would like to > > have to utilize optimistic locking. If it is just to output data you > > then have to clear() the persistence context before fetching new data. > > > > Probably we should add an Orchestra managed request scope too .... > > > > Ciao, > > Mario > > > > > >
