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