I dunno what the Gang of Four would suggest as the "best" approach,
but I think your life is going to be a heck of a lot easier if you just do
this:
public class MyServlet extends ApplicationServlet {
protected void doService(HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException {
HttpSession s = request.getSession();
Synchronized(s) {
super.doService(request, response);
}
}
That way access to each session is serialized without you needing to
set up any semaphores or whatnot.
--- Pat
> -----Original Message-----
> From: Lukáš Kolísko [mailto:[EMAIL PROTECTED]
> Sent: Sunday, August 07, 2005 5:25 PM
> To: Tapestry users
> Subject: Re: Hibernate Long term session
>
> Thanks a lot.
> So could this code be ok ?:
>
> private Semaphore semaphore;
>
> private static final String semaphoreName="semaphore";
>
> protected synchronized void setupSemaphore(RequestContext context){
> HttpSession session = context.getSession();
> if (session != null) {
> semaphore = (Semaphore)
> session.getAttribute(semaphoreName);
> if (semaphore == null) {
> semaphore = new Semaphore(1);
> }
> try {
> semaphore.acquire();
> session.setAttribute(semaphoreName,
semaphore);
> } catch (InterruptedException ex) {
> throw new ApplicationRuntimeException(ex);
> }
> }
> }
>
> protected void setupForRequest(RequestContext context) {
> setupSemaphore(context);
>
> //Get hibernate long term session from user session....
>
> super.setupForRequest(context);
> }
>
> protected void cleanupAfterRequest(IRequestCycle cycle) {
> super.cleanupAfterRequest(cycle);
> //Set hibernate long term session to user session ...
> semaphore.release();
> }
> I am really not sure about these things.
>
> I need to prevent race conditions globaly and serialize requests from
> user on his session.
>
> On 8/7/05, Pablo Ruggia <[EMAIL PROTECTED]> wrote:
> > The answer is no, you can not make session threadsafe when a user
> submits
> > twice, there will be two threads accesing the same hibernate session,
> wich
> > is not threadsafe.
> > But you can avoid users submitting twice, using Synchronizer Token
> Pattern (
> > http://www.javaworld.com/javaworld/javatips/jw-javatip136.html).
> >
> > On 8/7/05, Lukáš Kolísko <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello,
> > > maybe this is a newbie question, but is there a possible pattern how
> > > to implement long term session in Tapestry application in thread safe
> > > way.
> > >
> > > I am using tapestry ver. 3.0.3. I open session using ThreadLocal
> > > object from a static method when it is needed (The pattern show in
> > > Hibernate in Action book) and I close session using detach method of
> > > each page. This pattern works good for me, but when I want to use some
> > > object across many pages this pattern of course does not work with
> > > lazy initialization. I have to reconnect object to hibernate session
> > > or load a part of object tree into memory with lazy=false attributes (
> > > but this is very memory consuming )
> > >
> > > I am not sure if it is possible to use setupForRequest and
> > > cleanupAfterRequest methods to store hibernate session to user session
> > > and restore it after next request comes and connect it back to jdbc. I
> > > think this is not thread safe when user for example clicks more times
> > > submit button before the first request is completed. In this case more
> > > same hibernate session object would be taken from user session but
> > > after each request end the persistent session will be overwritten in
> > > non consistent way and hibernate session object is not thread safe
> > > itself.
> > >
> > > I would be very grateful for any suggestion or response.
> > > I solve this problem in my dissertation application.
> > >
> > > Sorry for my english.
> > >
> > > Lukas Kolisko
> > >
> > > ---------------------------------------------------------------------
> > > 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]
