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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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]
