I note that Session Settings allows you to have sessions expire as often as low as 15 minutes. However, I believe this is related to browser sessions and sure enough they do time out as expected.

However, I have a scheduled batch job (runs hourly) where I inject the Session Id as part of the initial state of the scheduled job (which then passes it to batch). The batch job then makes a callout using a REST service, e.g.:

    req.setHeader('Authorization', 'OAuth ' + sessionId );

This job has been running for over a day now and the session does not appear to expire.

As it happens, this behaviour is perfect for my use case but I am concerned it won't be reliable. When will the session timeout? Can I rely on it?

  • Perhaps I should clarify with a question first, is this a synchronous batch job or an asynchronous job? If synchronous, if I'm not mistaken, once the job goes into the batch queue, the batch job would operate under system credentials and your session time-out would no longer be an issue because the job would run whenever system resources become available. If asynchronous with @future calls, the same would apply. – crmprogdev May 4 '13 at 16:27
  • It's a batch job, which are inherently asynchronous so you do lose the session id from UserInfo.getSessionId(). – Phil Hawthorn May 4 '13 at 20:51
  • You're right, anything Apex is asynchronous. Don't know what I was thinking. Still learning about batch & future calls. Recalled having read that scheduled jobs may not run at exact time scheduled because SF might delay them until more resources are available. They have a lower priority than say a trigger. Much to learn! :) – crmprogdev May 5 '13 at 14:12
  • Indeed, think its future jobs that are run when resources are available. Batch jobs run immediately after you submit them assuming 1 of the 5 slots area available. Still learning myself what happens when things go wrong in that context. things are not always as they seem but fairly logical. – Phil Hawthorn May 5 '13 at 22:51

Sessions expire after the specified amount of idle time (see below), rather than an absolute time period. So, assuming your session timeout is at least an hour, you will keep it active by making a call every hour.

I wouldn't rely on this behavior for the long term, though. If the org admin reduces the session timeout, you will find your batch job failing. A more robust solution would be to do OAuth, keep the refresh token, and exchange it for an access token (aka session id) every hour (simpler) or whenever you get a session expired response (more efficient, but more complex).

The actual session timeout behavior, from the docs:

The last active session time value isn’t updated until halfway through the timeout period. That is, if you have a 30 minute timeout, the system won’t check for activity until 15 minutes have passed. For example, assume you have a 30 minute timeout value. If you update a record after 10 minutes, the last active session time value won’t be updated because there was no activity after 15 minutes. You’ll be logged out in 20 more minutes (30 minutes total) because the last active session time wasn’t updated. Suppose you update a record after 20 minutes. That’s five minutes after the last active session time is checked, so your timeout resets and you have another 30 minutes before being logged out, for a total of 50 minutes.

  • Hmm, I guess it's an unsupported feature then because I did reduce the timeout to 15 mins on my dev org. My job still ran successfully 20 mins later. Looks like I need to get my head in the docs re OAuth, I did start down that route but couldn't fathom a way to get the initial token without having the user do something (this is kind of a workaround). Thanks, you have answered the question @metadaddy. – Phil Hawthorn May 4 '13 at 19:13
  • 2
    You can use the username/password OAuth flow, but then you (obviously) need the user's username and password. Another pattern I've seen is for a server app to start a web server, open the browser to localhost:8080 (or whatever), do OAuth web server flow, then stop the web server. Easy to do in Node.js. – metadaddy May 5 '13 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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