the problem with keeping a reference to a hibernate object in session is that hibernate sessions are usually threadlocal, so there is a chance you will get an object from a different hiberante session, etc.
since hibernate caches by-id-lookup it isnt expensive to simply always load the object in getuser(). if you are not using hibernate you can either store the object in a threadlocal var in session or as a field in request cycle since request cycle is threadlocal itself. -igor On Jan 7, 2008 1:58 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > Ok, so you're saying make getUser return the object from the DAO (directly > or indirectly), synchronize the getters and setters and I don't have to > worry about any of this stuff? > > IMO, threading is never a simple issue. I just want a brain-dead solution > to this issue so I don't run into problems 1/100 times caused by code in my > websession implementation. > > -----Original Message----- > From: Igor Vaynberg [mailto:[EMAIL PROTECTED] > > Sent: Monday, January 07, 2008 1:54 PM > To: users@wicket.apache.org > Subject: Re: Wicket Session and threading > > and anyways, who cares, dont even need to cache it. let getuser() > always load it. hibernate caches for-id lookups anywho... > > -igor > > > On Jan 7, 2008 1:53 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > gah, i meant to put it into a threadlocal but forgot, oh well, use > > your imagination :) > > > > -igor > > > > > > > > On Jan 7, 2008 1:30 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > > > Igor! Thats a bad example. The user object should be in the websession > > > but the user object should be in the requestcycle. Because the > > > websession object can be hit by multiple request (threads) > > > > > > > > > On 1/7/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > class MySession extends WebSession { > > > > private Long userId; > > > > private transient User user; > > > > > > > > public SYNCHRONIZED void setUser(User user) { > > > > user=user; > > > > userId=(user==null)?null:user.getId(); > > > > } > > > > > > > > public SYNCHRONIZED void getUser() { > > > > if (user==null) { > > > > if (userId!=null) { > > > > user=getHibernateSession().load(User.class, userId); > > > > } > > > > } > > > > return user; > > > > } > > > > > > > > protected void onDetach() { > > > > user=null; > > > > } > > > > } > > > > > > > > -igor > > > > > > > > On Jan 7, 2008 11:11 AM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > > > > > Is there an example somewhere that shows how to do this? Or can > someone > > > > > paste a snippet here of how to do this? I assume a lot of webapps > have > > > > the > > > > > concept of a User object. > > > > > > > > > > -----Original Message----- > > > > > From: Martijn Dashorst [mailto:[EMAIL PROTECTED] > > > > > Sent: Saturday, January 05, 2008 5:17 AM > > > > > To: users@wicket.apache.org > > > > > Subject: Re: Wicket Session and threading > > > > > > > > > > > > > > > If you use hibernate, this is not recommended... An entity can only > be > > > > > part of one Hibernate Session, and storing the instance in the > wicket > > > > > session will share it across threads, and hence you'll get hibernate > > > > > exceptions. > > > > > > > > > > Note that this may not be only a problem in Hibernate, but can also > be > > > > > a problem in other db frameworks. > > > > > > > > > > So do what Johan described and you will be safe... > > > > > > > > > > Martijn > > > > > > > > > > On Jan 5, 2008 3:54 AM, Eelco Hillenius <[EMAIL PROTECTED]> > wrote: > > > > > > On Jan 5, 2008 5:15 AM, Dan Kaplan <[EMAIL PROTECTED]> > wrote: > > > > > > > Yeah that makes sense. Since we're sorta on the topic, I > thought I > > > > > would > > > > > > > ask this question. As the User object goes from being initially > > > > > registered > > > > > > > to its profile being edited, how does one update the User in the > > > > session > > > > > and > > > > > > > the db simultaneously? > > > > > > > > > > > > > > Here's a scenario: A user registers with your website and later > adds > > > > a > > > > > > > signature that is to show up on every post he makes. > > > > > > > > > > > > > > Do you add an instance of a UserService to your WebSession and > then > > > > have > > > > > > > this in it: > > > > > > > > > > > > > > private User user; > > > > > > > > > > > > > > public synchronized void setUser(User updatedUser) { > > > > > > > userService.updateUser(updatedUser); > > > > > > > this.user = updatedUser; > > > > > > > } > > > > > > > > > > > > > > public synchronized User getUser() { > > > > > > > return this.user; > > > > > > > } > > > > > > > > > > > > > > ? Cause I've been doing something like that. Is there a better > way > > > > to > > > > > go > > > > > > > about this? > > > > > > > > > > > > > > > > > > Looks fine to me. > > > > > > > > > > > > Eelco > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Buy Wicket in Action: http://manning.com/dashorst > > > > > Apache Wicket 1.3.0 is released > > > > > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
