There appears to be an issue keeping XPage sessions alive – even with the ExtLib keepSessionAlive control – which keeps the web session alive from the server’s perspective but does not keep the XPages session alive. This is a solution which works – especially for those people who are unable to use the Extension Library Add the following to the bottom of your XPage and what it will do is refresh the DIV preiodically based on your setting (in milliseconds) (300000 = 300 seconds = 5 minutes) – the longest I have had a successful test is 3.5 hours.
<xp:div id="keepSessionAlive"></xp:div>
<xp:scriptBlock id="scriptBlock1">
<xp:this.value>
<![CDATA[
XSP.addOnLoad(function(){
setInterval(function(){
XSP.partialRefreshPost("#{id:keepSessionAlive}", {});
}, 300000)
})]]>
</xp:this.value>
</xp:scriptBlock>
You need to set a value at least one minute less than the session timeout length set in the application properties for your database.
Do not set a short refresh time as this will needlessly waste bandwidth and also bloat IE’s RAM usage which is not well managed by the browser. Understand that this is a SECURITY ISSUE at the same time – by basically keeping an idle computer’s session alive you leave it open to hijack without the user’s knowledge – that is the part of the point of a timeout Thanks to Jeremy Hodge who helped figure out the optimal amount of code to do this in
Xomino 
Doesn’t this also introduce some memory issues on the server? Because sessions are kept in the server’s memory longer sessions for anonymous users will stack up and could lead eventually to out of memory errors?
Oh absolutely – but I don’t think a refresh once every 29 minutes is going to make any difference – there is definitely a balance.
I don’t like having to use this as a solution but because the XPages failiover once the session is lost is not good/non-existent then I am not sure there is an alternate.The user experience is compromised by selecting an action and at best nothing happening – because you might not be timed out of the web session you are still “logged in” but all your scoped variables are gone the results are not good.
An alternate would be to tell the user the session is expiring and not allow them to continue with their actions once they return – but that requires even more effort….something to think about.
Would an Alternative be – maybe after keeping alive for x number of minutes… to then just expire the session and redirect to a “Your session has expired” page? similar to what most financial institutions do if your idle too long?
Guess I’m asking what that effort might look like – to add a redirect to that function.
And yes – some effort – but could be very useful as a Custom Control – lemme see what i can come up with
Absolutely – but it all depends on the expectation of the clients and the requirements.
IT security should also have kittens over keeping the session alive with no user at the terminal – but hey I don’t make all the rules all the time 🙂
Two comments/questions. I have also run into this issue. The server side events on a radio button/select control stop working when the session times out and the user can change the values but the page never refreshes until they reload the entire page.
1. How can you tell if the session has timed out? It has to be a client side solution…I couldn’t figure out something.
2. So, I ended up using the meta tags to reload the page every x minutes. That seems to fix the issue. Probably more of a sledge hammer approach compared to Mark’s approach above!
Howard
Howard – yeah the META tag version refreshes the whole page – mine only a small hidden section so any current edits are not lost.
You could tell if a session has been lost by setting a sessionScope variable and using AJAX to make a call to the server and load it up on a separate XPage in the background – but you’d have to query the server to find out, the client cannot know if the session is lost without asking. Of course every time you ask you are also keeping the session alive.
oooooh we’ve discovered “The XPages Session Paradox” – you don’t know if it is alive until you ask and by asking you alter the state – SWEET Quantum XPages
Actually all my data (it filters a view) is already bound to sessionScope variables so a CSJS AJAX call to see if those are still valid would work well. I will experiment with that, thanks! Howard
Mark, I tried using a RPC call to get the session variable, which works fine but then stops working after the session times out (I think). Nothing happens when I click the button where the onclick event calls this CSJS function. The RPC method returns true when a sessionscope var is true and false when it is null or false…
function testInit() {
myRPC.getInit().addCallback(function(response) {
if (response == false){
alert(“reloading!”)
window.location.reload();
} else {
alert(“all ok”);
}
Howard
The bug had in fact been identified a few weeks ago and a fix had just been submitted to both n/d next (guess the number) and 853, which makes a hot fix possible while awaiting for the next fix pack. It is an unfortunate regression.
FYI, I’m using this control in every app, with a session timeout of 5 mins, and one page in memory for fast Ajax requests. Now, most of my pages make use of the dynamic content control, so the user is rarely navigating between pages. This is how I made my apps the most responsive!
Phil that is great to hear and I really appreciate you posting a response ! 🙂
Mark – just curious on what the thought process is for using XSP.partialRefreshPost vs XSP.partialRefreshGet?
Mike – I have no proof of this but I figured that a POST was more likely to force the session to stay alive than a GET. I did not test both.
I am having a similar issue where users are keeping a page open entering data for extended periods of time. To fix this I am doing an ajax call to essentially, as mentioned above, keep the session alive. This seems to work from the point of view of whether the user is logged in, but It seems as if occasionally the user does stay logged in, as in they have access to click buttons, do partial refreshes, and submit etc, as defined in the acl, but the Scope variables are dumped, in particular sessionScope. I am wondering if anyone else has noticed this using this keep alive method of maintaining a session?
This is the problem I experiences with the EXTLib Keep alive – just making an ajax call to the server keeps the LTPA Authentication Session active but not the XPage session. My feeling is that unless something on the XPage is touched then it is not kept alive.
I created this method specifically to keep the XPage session alive. Hope it works for you 🙂
Yes, you are exactly right! The ajax method keeps the auth session, but the xpage in memory is sometime lost along with some of the variables. When you click a coded action it reloads the last url request, which in some case is a new blank document, and in other is a previously saved document that no longer has your recent changes, hence it appears to have lost the data. The interesting thing is that it does not appear to be at a set interval, maybe its the Servers garbage collection, or based on active resources/memory? Anyway your solution works great, thanks for posting!
The XPages session length is set on the Application properties of the database. All sessions are also dropped if a build it made – one less thing we used to be able to do but can’t now (work on a production database *coughs politely*)
Right, that’s what I thought but I am seeing this problem regardless of the Session length setting and at intervals that seem to have no reference to a set time. Setting was at 3 hrs, now its at about 60min, and the dropped memory happens at 10 min, 15 or 20, very random I was actually originally going on that hunch that it was my development dropping sessions which as you say is also the case, and makes sense from the java perspective.
Thankyou MarkyRoden for the above “Session Alive” approach , we have been using it very Well in our Applications. Infact, as stated above, we dont face any problem with Session expiry, but Xpage failes to save information after a certain period of Time and this has been observed very randomly on dev environment
I would like to know what more are the main reason for this memory leaks besides rebuilt & refreshing the app. Do we have good information to know about it.
Besides above, I saw Me Medusa from Nathan Freeman (which I couldnt install in firefox 21 and YourKit (Java profiling) to observer the heap memory in Server side for the facet page. If you know any other plugins for the server side profiling, please let me know.
Thanks,
Sandeep.K
[…] For the server to keep a session active, it needs to know that the client is still there. The XPages Extension Library has a Keep Session Alive control, but it doesn’t seem to work very well. Instead, I use a period partial refresh. […]
[…] solutions popped up for those without the extension library (and to work around an earlier bug in the control, including Mark Roden’s XSnippet. In this solution, a timer is set to periodically trigger a […]