It's not really all that uncommon a pattern, as it saves you the
need to thread-safe your servlet and some things, like the infamous
Hibernate Long Session pattern really can't be made thread-safe so you just
end up synchronizing the whole thing to force serialization of each user's
requests.
The point is, I've shipped at least one commercial app with
precisely this kind of brute-force synchronization approach and never had a
problem, well, at least not a problem related to the synchronization block
:).
--- Pat
> -----Original Message-----
> From: Michael Prescott [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 26, 2005 10:20 AM
> To: Tapestry users
> Subject: Re: Design issue: synchronizing across callbacks?
>
> I was hoping for an option that wasn't quite as all-encompassing, but
> yes, I think that would do the trick.
>
> Patrick Casey wrote:
>
> > Would something as simple as this in your servelet's doService
> >method work for you?
> >
> > protected void doService(HttpServletRequest request,
> > HttpServletResponse response) throws IOException,
> >ServletException {
> > Clock c = new Clock();
> > HttpSession s = request.getSession();
> > fCurrentSession.set(s);
> > synchronized (s) {
> > super.doService(request, response);
> > }
> > String temp = "Total Render time = " + c;
> > Log.info(temp);
> > }
> >
> >
> >
> >>-----Original Message-----
> >>From: Michael Prescott [mailto:[EMAIL PROTECTED]
> >>Sent: Friday, August 26, 2005 8:28 AM
> >>To: [email protected]
> >>Subject: Design issue: synchronizing across callbacks?
> >>
> >>I have an application where certain screens can only be shown based on a
> >>user's state (in an underlying model). State changes with every page
> >>request (merely viewing the page can mean you're in a new state).
> >>
> >>Because users can double-click or click multiple links rapidly
> >>(effectively making concurrent, incompatible requests), I need to
> >>implement 'validity' checks correctly, redirecting requests for pages
> >>that shouldn't be shown.
> >>
> >>I can check the model's state in validate(), but that isn't sufficient
> >>because a concurrent request to a different page might change the model
> >>state immediately after the validate() call but before. I'm new enough
> >>to Tapestry that I'm not sure how I can synchronize access to my model
> >>at a scope that spans all of these callbacks.
> >>
> >>What's the typical way of handling this sort of thing?
> >>
> >>---------------------------------------------------------------------
> >>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]
> >
> >
> >
>
>
> --
> Michael Prescott
> wk.(416) 646-7062
> hm.(416) 686-8576
>
>
> ---------------------------------------------------------------------
> 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]
