Results 1 to 6 of 6

Thread: confused about handleRequestInternal

  1. #1
    Join Date
    Nov 2007
    Location
    Austin, TX USA
    Posts
    154

    Default confused about handleRequestInternal

    i chose to extend AbstractController for my controllers. When describing the workflow of this abstract class, the javadoc says this about the handoeRequestInternal() method which must be implemented by the user:
    Call abstract method handleRequestInternal() (optionally synchronizing around the call on the HttpSession), which should be implemented by extending classes to provide actual functionality to return ModelAndView objects.
    could someone explain to me why this is necessary? i dont understand what it means by synchronizing around the call on the HttpSession? I'd like to avoid having to copy and paste the handleRequest() code into this method for every controller if possible. Thanks.

  2. #2
    Join Date
    Nov 2007
    Location
    Austin, TX USA
    Posts
    154

    Default

    anyone got any ideas?

  3. #3
    Join Date
    Aug 2007
    Location
    Salt Lake City, Utah
    Posts
    7

    Default

    ew0kian,
    I would like to take a stab at explaining why you need to implement the handleRequestInternal method in each and every one of your controllers.

    Your controllers job is to take requests from clients and do something with them. Often this means hitting a DB, doing some logic, or simply displaying a page. The controller is expected to do something with that request, and you as the programmer are the only person who knows exactly what that thing is. That is why you have to implement the handleRequestInternal method. The spring controller can do everything but decided what to do.

    If your controllers simply display a page, then your implementation can be very easy, simply return a new ModelAndView with the view name and the model.
    Here is a very simple model and view that will display a view.
    Code:
    return new ModelAndView("viewName", new Hashtable());
    I hope this explains it without sounding like I know everything about what you are trying to do.

    Also:
    i dont understand what it means by synchronizing around the call on the HttpSession?
    I apologize, but I have never needed to wrap mine in a synchronized block in order to use sessions. So I don't know how to explain that part.

    Cheers
    Kblibr

  4. #4
    Join Date
    Oct 2006
    Posts
    228

    Default

    As already stated, handleRequestInternal is the method you override to provide your application logic. handleRequest is the method that will be invoked by Spring to kick off the controller's workflow. This will eventually call handleRequestInternal to allow your application logic to be invoked. One of the features that the AbstractController provides is synchoronizing on the Session - this means that any concurrent requests to the controller that come from the same client (as identified by the httpsession) will be serialized. You can turn this feature on or off (off by default) by setting the synchronizeOnSession property on the controller in the spring config.

    Hopefully this makes things clearer.

    Chris

  5. #5
    Join Date
    Nov 2007
    Location
    Austin, TX USA
    Posts
    154

    Default

    I took a look at the source and it looks like I don't have to implement handleRequest just handleRequestInternal. I had previously thought that you were to implement handleRequest and I had no knowledge of handleRequestInternal, because in the past i had only read about subclassing Controller instead of AbstractController.

    what are the advantages/disadvantages of synchronizing access to session data? in my application two people will not be logged in as the same user so i dont foresee any reason to "lock" sessions to prevent people from simultaneously modifying sesssion data and causing confusion.

  6. #6
    Join Date
    Oct 2006
    Posts
    228

    Default

    It depends on your application and what type of controllers you use. The main advantage is you don't need to worry about multiple simultaneous requests mucking up the session data and causing race conditions. Probably the major disadvantages are if you want to actually want to allow simultaneous client requests and there is probably a small performance hit.

    For controllers such as the SimpleFormController, I don't believe that access to session attributes is synchronized so there is potential for race conditions so synchronizing on the session is probably a good idea (maybe someone else could comment on this or you could check the source).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •