Announcement Announcement Module
No announcement yet.
pagination and continuation problem in SWF Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • pagination and continuation problem in SWF

    Hi ,
    There is another more serious problem l found ( l don't know whether it is serious or not , open for discussion ).
    Before describe the problem , l would like to ask some questions ,

    Q1. How to do paging in SWF ?
    As you can see from my previous posts in SWF forum , l concern about doing paging very much , l have no problem with my SimplePagingTag* with SpringMVC so far , but l do find the difficulty to do paging in SWF.
    The Simple Paging Tag are using initProperties() to init all those necessary properties for paging , the most important of the properties are parameters , l have to get all parameters from the request to make my paging work . In SWF , the parameters like _flowExecutionId , _eventId , ... are included too , otherwise l don't know what will happen if l lack one of them ... , so now the question :

    If l use continuation in my application ( using HttpSessionContinuationFlowExecutionStorage or ClientContinuationFlowExecutionStorage ) , the _flowExecutionId will change every time , then my makePageLink(..) method have to

    a. use the old flowExecutionId ? , or
    b. use the new flowExecutionId ?

    if (b) is the answer , then l have to change the method's implementation to depend on SWF API (because l have to know _flowExecutionId) , and the following behavior are unavoidable :

    Changing different tags each time l use different storages ... .. , this is strange action for me ...hihi

    Q2. Will paging + client continuation hit the limitation for "GET" easily ?
    The value of the parameter "_flowExecutionId" are so long for client continuation (Base64), my paging link have to include this _flowExecutionId for completion , what if my value of the other parameters are long too ? will it hit the limitation of http's "GET" ---> 128 easily ?

    P1. The "serious" problem...
    When l use continuation storages with my home make paging ( l think it can be generalized , just because it is so simple , it help to show all the problems ) , if l first search for a results , and press some of the links (<< 1 2 3 4 5>>) to another page , then keep pressing refresh button F5 , the problem shown - increase of memory . l open an Window Task Manager (Performance) to view the memory usage , it growth fast that l can see it with my eye , althought not fast enough to crash my system immediately , but this is not good~ , because if l want to crash my system , l just need to have something press on F5 button than go to sleep .

    l tried SpingMVC controller b4 , the momory won't increase too fast , because the SpringMVC controllers are not storing something , but not for the case of continuation ! l wrong about what l saw ? why there is an increase of memory so fast ? until now , l finished writing the article , the memory still not going down. Although l am not implement the cleanup flow filter in my test application , l guess it won't cause the problem , because it is regarding the expired flows , not an active flow .


    Last edited by robyn; May 16th, 2006, 03:45 AM.

  • #2
    have you tried looking at the PagedListHolder and RefreshablePagedListHolder classes? they make paging very easy and you should be able to delegate to hibernate quite easily (do a search on those classes and you'll find some examples).

    can you not store the necessary data inside the session to avoid long query strings? as long as you remove the data when you're done using it, you should be ok.

    i'm not sure about the memory issue - i tried out web flow for something i need to do (basically their phonebook example) but decided to go w/ a wizard controller instead - all of the examples are using jsps - i'm using velocity and unfortunately i don't have the time to investiage how things work.

    good luck!


    • #3
      jgangemi...b4 l came to the Simple Paging Tag , l have gone a long way , from displaytag , valuelist , PagedListHolder , .... a lot more , l used them . For pagedListHolder , you can refer to , , further more , you can see it from the sample application jpetstore - the codes for :
      public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception {
      		if (request.getParameter("search") != null) {
      			String keyword = request.getParameter("keyword");
      			if (keyword == null || keyword.length() == 0) {
      				return new ModelAndView("Error", "message", "Please enter a keyword to search for, then press the search button.");
      			else {
      				PagedListHolder productList = new PagedListHolder(this.petStore.searchProductList(keyword.toLowerCase()));
      				request.getSession().setAttribute("SearchProductsController_productList", productList);
      				return new ModelAndView("SearchProducts", "productList", productList);
      		else {
      			String page = request.getParameter("page");
      			PagedListHolder productList = (PagedListHolder) request.getSession().getAttribute("SearchProductsController_productList");
      			if ("next".equals(page)) {
      			else if ("previous".equals(page)) {
      			return new ModelAndView("SearchProducts", "productList", productList);
      You can see from the code above , the author do paging inside the controller , the controller collect "next" and "previous" parameters for paging , it is not portable and painful ... if you really study my codes for simple paging , l did not do that . The more serious part is the PagedListHolder collect a whole List.
      can you not store the necessary data inside the session to avoid long query strings?
      what is that mean ? did l store something inside the session ? did not do your homework b4 answering the question ....hihi..

      This is not a post concerning paging ....but more focus on continuation ...

      Last edited by robyn; May 16th, 2006, 03:34 AM.


      • #4
        The "serious" my careless.

        l test it using another computerB , let computerB make request through LAN to the computerA ( which is the server ) , no significance increase of memory was found --> that means the increase of memory is due to some other reason ..



        • #5
          Are you doing any other flow operations when you page (transitioning to a new state or anything)? Because, if not, you should be able to just reuse the old continuation id. By resubmitting the old state, you are effectively indicating that nothing has changed, and that you are still in the same old place - and from the sounds of it your paging is entirely independent of the web flow, so it should be safe to do this.


          • #6
            Yes , (a) also the answer l choose for Q1 .
            l want to know what other people think ,...especially the developers , because l don't know whether there is any caveat if l use it this way , for example , the simple paging tag fail in another situation in SWF ,

            Last edited by robyn; May 16th, 2006, 03:29 AM.


            • #7
              Backtracking slightly, as you've seen there is no guarantee that the id you submit will be the same as the one you get back. Strictly speaking, this is the case with any flow storage mechanism now, not just the continuation based ones. Using the client continuation storage mechanism and resubmitting the old id is effectively rolling back state to an earlier position and then submitting again, so you can get away with it if you don't change the state in any important way when you submit. Its a bit ugly though, quite brittle (as you are now dependent on a specific implementation of a specific storage strategy).

              This is a thorny problem - it looks like it might be a little tricky to get webflow to play nice with general purpose paging libraries now. It used to not matter with the original session-based storage mechanism as the flow id was always the same, and reasonably short. Now the flow id can change (even with a traditional session based storage mechanism), and with continutations the id can probably be so long as to break GETs.