Sorry about my ignorance on the subject, but will this work in an a 
clustered enviroment ? You are synchornizing just in one server. So two 
servers will be attending at same time the same user.

On 8/7/05, Patrick Casey <[EMAIL PROTECTED]> wrote:
> 
> 
> 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]
> 
>

Reply via email to