2

When an org has a session timeout value set and the user is interacting with a Visualforce page where the only postback action that the page performs occurs using rerenders, the session will eventually timeout. (or the session timer script running in the page expires)

The big problem with this particular timeout scenario is that the user may have been manipulating a significant amount of data within the page context and not yet committed any of it to the database... which can cause them to lose all of this as-yet-uncommitted data.

I have attempted to manipulate the sessionTimer script which is running in the page using the oncomplete callback of the rerender in the past but have yet to be successful at keeping a 'long running' multiple-postback with rerenders page from eventually timing out and causing grief to the user.

There exists a similar question about RemoteAction calls - but it does not address the issue of the session timer within the context of the page. Remote Actions and Session Timeout Question

Is there a best-practice way to solve this problem? (aside from informing the user that they must commit their changes before the session timer expires)

Update Example

An example which has been shown to exhibit this behavior is an Account & Contact input/edit screen on the same page. The upper section of the page shows the Account details and the lower section allows the user to [add|edit|remove] Contact records related to this Account.

The interface includes a button "Add Contact" (with a rerender attribute) which inserts a new Contact record into a List collection on the controller and then rerenders the List<Contact> in the page for presentation to the user for additional input.

If the org has a 15 minute session timeout and the user spends 20 minutes manipulating data in this page and the only POST behavior which has been happening is rerenders, when the user clicks the "Save" button to perform the DML operation and commit their in-page changes they are immediately shown the expired session screen and all of their changes are lost.

Improve this question

1 Answer 1

Reset to default
2

It seems like users must have uncommitted data lying around for a long time for this to happen. I don't know a way of dealing with the timer, but would saving the data periodically into a record with a "draft" status (indicated by a picklist field or similar) offer a better approach?

You could save the information automatically using <apex:actionSupport> elements when various form fields change, then update the status when the user specifically requests to save the record. You'd probably want a scheduled job triggering a batch process once a day killing temporary records that are more than 24 hours old or so to keep the system clean.

Improve this answer
2
  • The frequent save action on the user's behalf would definitely provide a safe fallback mechanism. There is a secondary issue though in that this page also allows editing of existing records and the user must have the ability to cancel and abandon their changes. Performing an auto-save on the user's behalf and providing the ability to abandon the 'draft' changes would complicate the code and the data a little bit, but it is a viable alternative.
    – Mark Pond
    Commented Sep 11, 2013 at 16:45
  • Yeah that would definitely add a complication, though I guess it'd just take a draft record that gets copied back (and then deleted) when the real save button is clicked. Prob need a lookup tied to the record so when reloading the page you know which draft to load (check for ownership too).
    – Matt Lacey ♦
    Commented Sep 11, 2013 at 23:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .