Isn't it a bad idea to keep any non-thread-safe objects in the session? Sharing entities sounds particularly risky since any persistence session other than the original that, say, tries to initialize a lazy collection will result in a runtime exception.
Because of this, our application maintains the user primary key in the Wicket Session (using metadata), but it gets loaded through a RequestCycle subclass. No need to worry about concurrent access or detach() logic there. On Mon, Oct 3, 2011 at 1:31 AM, Martin Grigorov <[email protected]>wrote: > On Mon, Oct 3, 2011 at 10:24 AM, Carl-Eric Menzel <[email protected]> > wrote: > > On Mon, 3 Oct 2011 01:10:58 -0700 (PDT) > > Zeldor <[email protected]> wrote: > > > >> But would it be possible to store User data in the session without > >> having to fetch it from datastore on every request? My users don't > >> interact with each other and they operate only on their own data. So > >> it'd be most efficient to store User data in the session and interact > >> with db only when some data is changed. > > > > Yes, just put a field in your Session and add getter/setter. > This is not good. > This is error prone. This way you'll have to keep the instance in the > Session in sync with the data DB. Additionally the memory size will > increase for no reason. Select by primary key (user id) is fast > operation. > > > > Carl-Eric > > www.wicketbuch.de > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
