Tuesday, April 15, 2008

Session timeouts, profile options and adconfig for the Oracle eBusiness Suite

Tired of your Oracle eBusiness Sessions timing out?

Symptoms:

Your log on session is no longer valid. Would you like to log back in so you can continue working? If you do not log in, any outstanding data changes in your forms will not be saved.
Your Session has expired, please login again

Solution:

Set the values of the following profile options appropriately. See Note:171261.1 for details:

ICX:Session Timeout
E.g. From 30 to null (minutes)

ICX: Limit time
E.g. From 10 to 24 (hours)

But when you refresh or clone Test / Development environments the setting for ICX:Session Timeout gets reset!

No problem just need to find the appropriate variable in the adconfig context file e.g. $APPL_TOP/admin/$CONTEXT_NAME.xml.

<session_timeout oa_var="s_sesstimeout">1800000</session_timeout>

And set to the appropriate value. Note that s_sesstimeout is in milliseconds so multiple by (1000*60) to get the time in minutes that is represented in the profile option.

E.g. if you want to set it to 60 minutes then in the context file put value 60 * 1000 * 60 = 3600000. Either that or just set to null:

<session_timeout oa_var="s_sesstimeout">1800000</session_timeout>

Then next time you run adconfig.sh (or a patch/clone does) then you won't have to reset profile options.

5 comments:

Mike Shaw said...

Bear in mind note 171261.1 was written around 2002, way before OA Framework was being used extensively, so doesn't mention the increased memory consumption on the middle tiers OACore JVMs when increasing the user timeout.

You also need to consider the security implications.... do you really want to allow users to leave their screens logged in if they leave their screens unattended for a long period of time (over lunch or over night)

Gareth said...

Hi Mike,

Thanks for the comments.

Re security considerations, a better solution would be to employ an organization-wide password protected screensaver. That way you protect all the desktop apps irrespective of whether they have session timeouts. Also the network layer is somewhat more protected. Many, many organizations completely overlook the network layer - how many password protected TNS Listeners do you encounter?

Yes - if you make the changes I allude to and you are running a high volume system then watch the memory consumption and adjust as necessary. Anyone had any issues with this?

Re Note 171261.1 it was reviewed Nov 2006 so still somewhat relevant - just haven't had the chance to find a newer one with the same info!! Please point one out if you see it.

Thanks,
Gareth

David Haimes said...

I understand one of the main reasons to put in those options was performance.

Particularly in a self service environment you may have a huge number of sessions which is going to hurt the middle tier memory and performance a lot.

Gareth said...

Hi David,

Do you have any metrics that relate the lengthening of these timeouts to memory consumption under say 11.5.10.2 architecture, especially what the impact is (e.g. does the unused session memory just get paged out)?

Anyone have specific examples?

Thanks,
Gareth

David Haimes said...

I haven't seen (or looked for) any metrics. My personal experience was a noticable difference in testing environments if the profile was set to null. However our test environments are not designed for performance!

Would be interesting to hear any experience or metrics from the field