mattwhite.me

Yesterday, Ben Poole and myself presented the XPages101 course which I have designed over the last couple of months to be an introduction to developing with XPages.

Overall it seemed to go pretty well, the timings need some work, I went a little fast at some points which may have left a few people overwhelmed at the fire hose of information we got through in a short period of time! That will not happen again now that I understand how it all hangs together a bit more.

The feedback from the attendees was really gratifying...

Obviously there's always room for improvement and there were some great feedback comments as well...

"A real eye opener for me as I've not looked XPages prior to the course."

"Excellent value for money. Pitched just right for the first steps into XPages."

"It gave me a very good understanding of XPages under the bonnet."

"It was great being here, great course, the XPages start I was looking for."

One of the things which I had consciously not done was provide lots of handout materials. The aim was to reduce the costs of the course as much as possible. From the feedback it seems people would have been happy to pay extra to get more paper based materials. So I think in future iterations of the course we'll change that around.

The other area where a couple of people expressed an interest was for an "intermediate" course. This leaves me in a bit of a quandary, as I'm not sure I know what intermediate is. So if you have any thoughts I'd love to hear them.

Overall though, as I said earlier, it was a great day. Good fun for me, and hopefully useful to everyone else.

When is a session not a session?

Most Domino web sites these days will be running some form of session authentication which stores a cookie on the user's browser and a tiny piece of memory with details about the user on the server. This has always worked fine, and of course these sessions can time out (by default after 30 minutes).

But with the advent of XPages we now also have the sessionScope variable container which allows us to store information about a user's session (whether they are authenticated or not). This offers us huge opportunities for performance improvements as it means we don't need to keep on doing @DbLookups to get user specific information for every page load. But it does introduce some potential issues if the authentication session timeouts are different to the sessionScope timeouts.

Basically the server needs to be able to clear out sessionScope variables after an amount of time, otherwise the server would run out of memory very quickly indeed. But in a recent project we had users who would open a page and then come back to it 2 or 3 hours later and then wonder why everything had stopped working. This is because the default timeout for sessionScope variables is something around 30 minutes and our session timeouts were set to 2 hours.  So once the page had been left inactive for half an hour it effectively lost all of the background information that drove how it should act when the user pressed the save button for example.

The solution is very simple, but very important. In the application properties for your database (opened in Domino Designer these days remember), go to the XPages tab and make sure to set the Session timeout field to be more than the authentication Session Timeout (which you set in the server or website document). The rule of thumb that we have come to (in the absence of any official guidelines from IBM) is that if you have a 2 hour authentication timeout for your website, then set the XPages Session Timeout to 3 hours.

Generally the application timeout is less important for this sort of thing, but we took the opportunity to also set that to 3 hours in this case as I knew it wouldn't be too large.

There are, of course, caveats here. If your server has memory issues then this is only going to exacerbate them as for each user (remember a user is just a visitor to the website, not necessarily someone who logs in) is going to take up some memory from the server for a minimum of 3 hours, but for us it solves more problems than it causes.

Of course, if you are not using the sessionScope to store any page sensitive data then you can just ignore all of this, but once you start using the sessionScope, it does become rather addictive, so I suspect you will get some benefit from setting this variable. Either way if you start to see completely bizarre errors, this may be a good first port of call.

Hopefully this article will save someone the pain of trying to debug seemingly un-reproducible errors in a dev environment where you don't have the time to leave pages inactive for hours on end!