Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

While researching some information regarding managing state and session in web applications, I stumbled across this nugget of information:

67 is the first useful prime number after 60. (Yes, 61 is a prime, too, but it's too close to 60 to be of use.) Setting timeouts in durations of primes is common because it lessens the likelihood that two timeout sessions will overlap.

Of course, that's completely anecdotal and may not in any way be the reason why they chose 67 minutes, but that's always made sense to me.

At first glance, this seems to make perfect sense to me, and traditionally, I've never given a lot of thought to the variance of sessions timing out, but I wonder how much (if any) this strategy has been put into place in practice? Would making a change to timeouts ending on prime numbers really have that much of an effect long-term in a large scale application? Or would a change like this go mostly unnoticed?

In other words, is this really anecdotal? Or is it something that should be strongly considered as a best practice?

share|improve this question
2  
Why does a prime duration lessen the likelihood that two timeout sessions will overlap? –  StuperUser Jan 17 '12 at 17:07
2  
Hopefully someone who is far better at math and statistics than I can swoop in and explain why/prove that it doesn't. –  Shawn Holmes Jan 17 '12 at 17:08
8  
If two sessions start at the same time, no matter what the timeout is, they will be closed at the same time too...... –  marco-fiset Jan 17 '12 at 17:17
1  
Timeout sessions of what? Two different servers? Two instances of the same application? Two user sessions? Database session vs user session timeout? –  Mike Cellini Jan 17 '12 at 17:27
6  
I think there is some confusion here. If two events start at the same time and they repeat every x and y minutes respectively, then decrease the number of times they meet again one should choose x and y relatively prime. This has nothing to do with the heuristics suggested here: if the period is the same for all events, its actual value is irrelevant. In fact, the actual value depends on the unit, and it is just arbitrary to use minutes here. –  Andrea Jan 17 '12 at 17:57
show 5 more comments

2 Answers

I believe what the author was getting at was not that two web sessions would be less likely to end at the same time if they were each 67 minutes long, but rather that the end of web sessions would be less likely to overlap with other events (like the server being cycled, backups going off, system going down for maintenance, updates being applied) that tend to be an exact number of hours (often 24 or a multiple of it) apart.

All of this only matters if important and timeconsuming work happens at session end (I have written systems that persist unsaved drafts on session end just in case).

share|improve this answer
3  
Even this formulation would be false, since sessions start at a random time –  Andrea Jan 17 '12 at 21:29
1  
most sessions do, but the ones that start right after a reset start together. However they last a random time, so I am losing confidence in the theory fast. –  Kate Gregory Jan 17 '12 at 21:32
add comment

This sounds like cargo cult programming. Session timeouts occur based on user action and while some patterns for that can be seen on a large enough time scale, they only become relevant at time scales orders of magnitude larger (eg. most session time-outs happen at lunch or closing hours).

In practice session time-out periods are set around the 15-20 minute mark. There are deviations because the end user may want them, but anything above that is kind of a security risk and anything below is an inconvenience to the user.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.