Re: Wicket Session and threading
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
> > &g
RE: Wicket Session and threading
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() {
> > &g
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]
Re: Wicket Session and threading
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]
Re: Wicket Session and threading
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]
RE: Wicket Session and threading
Ok, thanks
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, January 07, 2008 11:32 AM
To: users@wicket.apache.org
Subject: Re: Wicket Session and threading
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]
Re: Wicket Session and threading
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]
RE: Wicket Session and threading
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]
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]
Re: Wicket Session and threading
Only store the userid in the session, and get that id and the user
object in the request cycle on begin request also store the user
object in that request cycle then no synching is really needed, except
maybe a (db) version/timestamp check if you really want to make sure
you are the latest update.
On 1/4/08, 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?
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Frank Bille
> Sent: Friday, January 04, 2008 2:02 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket Session and threading
>
> What about (i)frames with pages being loaded in every one of them at the
> same time?
>
> Frank
>
>
> On Jan 4, 2008 7:57 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote:
>
> > To me it seems like it would be an unusual situation for two threads to
> > access the session at the same time. Under what circumstances does this
> > happen?
> >
> > -Original Message-
> > From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, January 03, 2008 10:15 PM
> > To: users@wicket.apache.org
> > Subject: Re: Wicket Session and threading
> >
> > You're right, we should mention this in WIA. Would you mind leaving a
> > comment on the author forum?
> > http://www.manning-sandbox.com/forum.jspa?forumID=328
> >
> > Cheers,
> >
> > Eelco
> >
> > On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> > >
> > > Eelco Hillenius wrote:
> > > >> Am I right in concluding that I must make my wicket session
> > thread-safe?
> > > >>
> > > >> That is, if I want to store an "int" value in the session, I should
> > use
> > > >> a volatile or AtomicInteger?
> > > >
> > > > Yes. We try our best to make pages/ components as thread safe as
> > > > possible, but making the session thread safe would impose a too large
> > > > performance penalty.
> > > >
> > > >> Is there anywhere a small piece on how to deal with threading within
> > > >> Wicket (i.e., what is/is not synchronized in a request/response
> > > >> roundtrip?). I did some quick searching in the mailing list archives
> > and
> > > >> google, but could not find anything related to version 1.3.
> > > >
> > > > Pages are synced on pagemaps, which basically relates to browser
> > > > windows. RequestCycles are separate instances which are not reused, so
> > > > no sync needed there. Sessions are not synced so you need to sync
> > > > manually. Though in practice this wouldn't give much trouble to start
> > > > with. Applications are shared an not synced.
> > > >
> > > > Eelco
> > >
> > > Thanks for the answer. :-)
> > >
> > > Before really thinking about it I kind of implicitly assumed that
> > > session access was synced. It hasn't really gone wrong yet either, but
> > > that's probably because of the use of ThreadLocal which acts as a memory
> > > barrier (for session/application) and the fact that it's very hard to
> > > get two threads to interleave within one session unless you start having
> > > a fit on the mouse (or use lots of autoupdating ajaxy stuff).
> > >
> > > It could be (very) useful to have this info in the Wicket in Action book
> > > though. For example in listing 2.1 there is a Session object with a
> > > get/setUser, but it is completely unsynchronized; similarly, there is no
> > > synchronization at all on the Cheesr session. Again the visibility seems
> > > to be ensured by the fact that the session is set in a thread local, but
> > >
Re: Wicket Session and threading
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]
Re: Wicket Session and threading
On Jan 5, 2008 5:02 AM, Frank Bille <[EMAIL PROTECTED]> wrote: > What about (i)frames with pages being loaded in every one of them at the > same time? Or images that are resources for instance. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket Session and threading
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?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Frank Bille
Sent: Friday, January 04, 2008 2:02 PM
To: users@wicket.apache.org
Subject: Re: Wicket Session and threading
What about (i)frames with pages being loaded in every one of them at the
same time?
Frank
On Jan 4, 2008 7:57 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote:
> To me it seems like it would be an unusual situation for two threads to
> access the session at the same time. Under what circumstances does this
> happen?
>
> -Original Message-
> From: Eelco Hillenius [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 03, 2008 10:15 PM
> To: users@wicket.apache.org
> Subject: Re: Wicket Session and threading
>
> You're right, we should mention this in WIA. Would you mind leaving a
> comment on the author forum?
> http://www.manning-sandbox.com/forum.jspa?forumID=328
>
> Cheers,
>
> Eelco
>
> On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> >
> > Eelco Hillenius wrote:
> > >> Am I right in concluding that I must make my wicket session
> thread-safe?
> > >>
> > >> That is, if I want to store an "int" value in the session, I should
> use
> > >> a volatile or AtomicInteger?
> > >
> > > Yes. We try our best to make pages/ components as thread safe as
> > > possible, but making the session thread safe would impose a too large
> > > performance penalty.
> > >
> > >> Is there anywhere a small piece on how to deal with threading within
> > >> Wicket (i.e., what is/is not synchronized in a request/response
> > >> roundtrip?). I did some quick searching in the mailing list archives
> and
> > >> google, but could not find anything related to version 1.3.
> > >
> > > Pages are synced on pagemaps, which basically relates to browser
> > > windows. RequestCycles are separate instances which are not reused, so
> > > no sync needed there. Sessions are not synced so you need to sync
> > > manually. Though in practice this wouldn't give much trouble to start
> > > with. Applications are shared an not synced.
> > >
> > > Eelco
> >
> > Thanks for the answer. :-)
> >
> > Before really thinking about it I kind of implicitly assumed that
> > session access was synced. It hasn't really gone wrong yet either, but
> > that's probably because of the use of ThreadLocal which acts as a memory
> > barrier (for session/application) and the fact that it's very hard to
> > get two threads to interleave within one session unless you start having
> > a fit on the mouse (or use lots of autoupdating ajaxy stuff).
> >
> > It could be (very) useful to have this info in the Wicket in Action book
> > though. For example in listing 2.1 there is a Session object with a
> > get/setUser, but it is completely unsynchronized; similarly, there is no
> > synchronization at all on the Cheesr session. Again the visibility seems
> > to be ensured by the fact that the session is set in a thread local, but
> > the code somehow seems to suggest (to me anyway) that no synchronization
> > is necessary...
> >
> > There are some comments on multithreadedness and threads (2.3; but in
> > the context of detaching, not thread-safety, and 4.1.1 in the context of
> > the Application object). However it also says (in 4.1.1) that all is
> > safe if the Application only has read-only properties, however, in the
> > CheesrApplication the list of cheeses is not final. This must mean that
> > Wicket does ensure visibility (or else it's a bug ;-)), but that is not
> > trivial and should probably be mentioned.
> >
> > Regards,
> > Sebastiaan
> >
>
> -
> 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]
Re: Wicket Session and threading
What about (i)frames with pages being loaded in every one of them at the same time? Frank On Jan 4, 2008 7:57 PM, Dan Kaplan <[EMAIL PROTECTED]> wrote: > To me it seems like it would be an unusual situation for two threads to > access the session at the same time. Under what circumstances does this > happen? > > -Original Message- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 03, 2008 10:15 PM > To: users@wicket.apache.org > Subject: Re: Wicket Session and threading > > You're right, we should mention this in WIA. Would you mind leaving a > comment on the author forum? > http://www.manning-sandbox.com/forum.jspa?forumID=328 > > Cheers, > > Eelco > > On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > > > > Eelco Hillenius wrote: > > >> Am I right in concluding that I must make my wicket session > thread-safe? > > >> > > >> That is, if I want to store an "int" value in the session, I should > use > > >> a volatile or AtomicInteger? > > > > > > Yes. We try our best to make pages/ components as thread safe as > > > possible, but making the session thread safe would impose a too large > > > performance penalty. > > > > > >> Is there anywhere a small piece on how to deal with threading within > > >> Wicket (i.e., what is/is not synchronized in a request/response > > >> roundtrip?). I did some quick searching in the mailing list archives > and > > >> google, but could not find anything related to version 1.3. > > > > > > Pages are synced on pagemaps, which basically relates to browser > > > windows. RequestCycles are separate instances which are not reused, so > > > no sync needed there. Sessions are not synced so you need to sync > > > manually. Though in practice this wouldn't give much trouble to start > > > with. Applications are shared an not synced. > > > > > > Eelco > > > > Thanks for the answer. :-) > > > > Before really thinking about it I kind of implicitly assumed that > > session access was synced. It hasn't really gone wrong yet either, but > > that's probably because of the use of ThreadLocal which acts as a memory > > barrier (for session/application) and the fact that it's very hard to > > get two threads to interleave within one session unless you start having > > a fit on the mouse (or use lots of autoupdating ajaxy stuff). > > > > It could be (very) useful to have this info in the Wicket in Action book > > though. For example in listing 2.1 there is a Session object with a > > get/setUser, but it is completely unsynchronized; similarly, there is no > > synchronization at all on the Cheesr session. Again the visibility seems > > to be ensured by the fact that the session is set in a thread local, but > > the code somehow seems to suggest (to me anyway) that no synchronization > > is necessary... > > > > There are some comments on multithreadedness and threads (2.3; but in > > the context of detaching, not thread-safety, and 4.1.1 in the context of > > the Application object). However it also says (in 4.1.1) that all is > > safe if the Application only has read-only properties, however, in the > > CheesrApplication the list of cheeses is not final. This must mean that > > Wicket does ensure visibility (or else it's a bug ;-)), but that is not > > trivial and should probably be mentioned. > > > > Regards, > > Sebastiaan > > > > - > 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] > >
RE: Wicket Session and threading
To me it seems like it would be an unusual situation for two threads to access the session at the same time. Under what circumstances does this happen? -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Thursday, January 03, 2008 10:15 PM To: users@wicket.apache.org Subject: Re: Wicket Session and threading You're right, we should mention this in WIA. Would you mind leaving a comment on the author forum? http://www.manning-sandbox.com/forum.jspa?forumID=328 Cheers, Eelco On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > > Eelco Hillenius wrote: > >> Am I right in concluding that I must make my wicket session thread-safe? > >> > >> That is, if I want to store an "int" value in the session, I should use > >> a volatile or AtomicInteger? > > > > Yes. We try our best to make pages/ components as thread safe as > > possible, but making the session thread safe would impose a too large > > performance penalty. > > > >> Is there anywhere a small piece on how to deal with threading within > >> Wicket (i.e., what is/is not synchronized in a request/response > >> roundtrip?). I did some quick searching in the mailing list archives and > >> google, but could not find anything related to version 1.3. > > > > Pages are synced on pagemaps, which basically relates to browser > > windows. RequestCycles are separate instances which are not reused, so > > no sync needed there. Sessions are not synced so you need to sync > > manually. Though in practice this wouldn't give much trouble to start > > with. Applications are shared an not synced. > > > > Eelco > > Thanks for the answer. :-) > > Before really thinking about it I kind of implicitly assumed that > session access was synced. It hasn't really gone wrong yet either, but > that's probably because of the use of ThreadLocal which acts as a memory > barrier (for session/application) and the fact that it's very hard to > get two threads to interleave within one session unless you start having > a fit on the mouse (or use lots of autoupdating ajaxy stuff). > > It could be (very) useful to have this info in the Wicket in Action book > though. For example in listing 2.1 there is a Session object with a > get/setUser, but it is completely unsynchronized; similarly, there is no > synchronization at all on the Cheesr session. Again the visibility seems > to be ensured by the fact that the session is set in a thread local, but > the code somehow seems to suggest (to me anyway) that no synchronization > is necessary... > > There are some comments on multithreadedness and threads (2.3; but in > the context of detaching, not thread-safety, and 4.1.1 in the context of > the Application object). However it also says (in 4.1.1) that all is > safe if the Application only has read-only properties, however, in the > CheesrApplication the list of cheeses is not final. This must mean that > Wicket does ensure visibility (or else it's a bug ;-)), but that is not > trivial and should probably be mentioned. > > Regards, > Sebastiaan > - 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]
Re: Wicket Session and threading
You're right, we should mention this in WIA. Would you mind leaving a comment on the author forum? http://www.manning-sandbox.com/forum.jspa?forumID=328 Cheers, Eelco On Jan 3, 2008 11:10 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > > Eelco Hillenius wrote: > >> Am I right in concluding that I must make my wicket session thread-safe? > >> > >> That is, if I want to store an "int" value in the session, I should use > >> a volatile or AtomicInteger? > > > > Yes. We try our best to make pages/ components as thread safe as > > possible, but making the session thread safe would impose a too large > > performance penalty. > > > >> Is there anywhere a small piece on how to deal with threading within > >> Wicket (i.e., what is/is not synchronized in a request/response > >> roundtrip?). I did some quick searching in the mailing list archives and > >> google, but could not find anything related to version 1.3. > > > > Pages are synced on pagemaps, which basically relates to browser > > windows. RequestCycles are separate instances which are not reused, so > > no sync needed there. Sessions are not synced so you need to sync > > manually. Though in practice this wouldn't give much trouble to start > > with. Applications are shared an not synced. > > > > Eelco > > Thanks for the answer. :-) > > Before really thinking about it I kind of implicitly assumed that > session access was synced. It hasn't really gone wrong yet either, but > that's probably because of the use of ThreadLocal which acts as a memory > barrier (for session/application) and the fact that it's very hard to > get two threads to interleave within one session unless you start having > a fit on the mouse (or use lots of autoupdating ajaxy stuff). > > It could be (very) useful to have this info in the Wicket in Action book > though. For example in listing 2.1 there is a Session object with a > get/setUser, but it is completely unsynchronized; similarly, there is no > synchronization at all on the Cheesr session. Again the visibility seems > to be ensured by the fact that the session is set in a thread local, but > the code somehow seems to suggest (to me anyway) that no synchronization > is necessary... > > There are some comments on multithreadedness and threads (2.3; but in > the context of detaching, not thread-safety, and 4.1.1 in the context of > the Application object). However it also says (in 4.1.1) that all is > safe if the Application only has read-only properties, however, in the > CheesrApplication the list of cheeses is not final. This must mean that > Wicket does ensure visibility (or else it's a bug ;-)), but that is not > trivial and should probably be mentioned. > > Regards, > Sebastiaan > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket Session and threading
Eelco Hillenius wrote: Am I right in concluding that I must make my wicket session thread-safe? That is, if I want to store an "int" value in the session, I should use a volatile or AtomicInteger? Yes. We try our best to make pages/ components as thread safe as possible, but making the session thread safe would impose a too large performance penalty. Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. Eelco Thanks for the answer. :-) Before really thinking about it I kind of implicitly assumed that session access was synced. It hasn't really gone wrong yet either, but that's probably because of the use of ThreadLocal which acts as a memory barrier (for session/application) and the fact that it's very hard to get two threads to interleave within one session unless you start having a fit on the mouse (or use lots of autoupdating ajaxy stuff). It could be (very) useful to have this info in the Wicket in Action book though. For example in listing 2.1 there is a Session object with a get/setUser, but it is completely unsynchronized; similarly, there is no synchronization at all on the Cheesr session. Again the visibility seems to be ensured by the fact that the session is set in a thread local, but the code somehow seems to suggest (to me anyway) that no synchronization is necessary... There are some comments on multithreadedness and threads (2.3; but in the context of detaching, not thread-safety, and 4.1.1 in the context of the Application object). However it also says (in 4.1.1) that all is safe if the Application only has read-only properties, however, in the CheesrApplication the list of cheeses is not final. This must mean that Wicket does ensure visibility (or else it's a bug ;-)), but that is not trivial and should probably be mentioned. Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: Wicket Session and threading
> Am I right in concluding that I must make my wicket session thread-safe? > > That is, if I want to store an "int" value in the session, I should use > a volatile or AtomicInteger? Yes. We try our best to make pages/ components as thread safe as possible, but making the session thread safe would impose a too large performance penalty. > Is there anywhere a small piece on how to deal with threading within > Wicket (i.e., what is/is not synchronized in a request/response > roundtrip?). I did some quick searching in the mailing list archives and > google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
