Tapestry
  1. Tapestry
  2. TAPESTRY-1101

@Persist("session") does not make the accessor fetch from session everytime

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 4.0.2
    • Fix Version/s: 4.1.2
    • Component/s: tapestry-core
    • Labels:
      None

      Description

      I was going through the Persistence mechanism implementations in Tapestry 4.0.2 and came across the following behaviour:

      ----------------------
      For properties marked as @Persist("session"), the mutator(setter) stores the value in a instance variable and also puts it into session using the corresponding persistence strategy. But the accessor(getter) just fetches the value stored in the instance variable and does not check for an updated value within the session.
      ----------------------

      This entire approach works fine until we start getting multiple simultaneous requests within the same session (which is possible when using asynchronous requests).

      Here's a sample scenario where the above approach may cause a problem:

      ----------------------
      Assume that 2 asynchronous requests (say 2 lookups) are running of the same page (same page class, but 2 different instances), simultaneously.

      If Request#1 updates an @Persist("session") property value, Request#2 will not see this updated value as the accessor of that property.
      ----------------------

      Is what I have mentioned here right? Or is there something in the code that escaped my notice?

        Activity

        Hide
        Jesse Kuhnert added a comment -

        Right - this is for performance reasons. In clustered environments actually reading from / to the session on every access would be a huge drain on performance. If an actual problem creeps up we will of course address it but I'm wondering if this is really a problem for you?

        Show
        Jesse Kuhnert added a comment - Right - this is for performance reasons. In clustered environments actually reading from / to the session on every access would be a huge drain on performance. If an actual problem creeps up we will of course address it but I'm wondering if this is really a problem for you?

          People

          • Assignee:
            Unassigned
            Reporter:
            B.S.Navin
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development