Sunday, January 20, 2013

About ICX Session

About ICX Session

ICX:Session Timeout
30 (minutes)
ICX: Limit Time
4 (hours)
4 (hours)
ICX: Limit Connect

    ICX:Session Timeout - This profile option determines the length of time (in minutes) of inactivity in a user's form session before the session is disabled.  Note that disabled does not mean terminated or killed.  The user is provided the opportunity to re-authenticate and re-enable their timed-out session. If the re-authentication is successful, the disabled session is re-enabled and no work is lost. Otherwise, the session is terminated without saving pending work.  This functionality is available via Patch 2012308 (included in 11.5.7, FND.E).  Note: Setting the profile value to greater than 30 minutes can drain the JVM resources and cause ‘out of memory’ errors.
·   ICX: Limit time - This profile option defines the maximum connection time for a connection – regardless of user activity.  If 'ICX:Session Timeout' is set to NULL, then the session will last only as long as 'ICX: Limit Time', regardless of user activity. 
·   ICX: Limit connect - This profile option defines the maximum number of connection requests a user can make in a single session. Note that other EBS internal checks will generate connection requests during a user session, so it is not just user activity that can increment the count. 

  • Jserv(Java)TimeoutSettings

5400000 (milliseconds)
55 (minutes)
5400000 (milliseconds)
360  (seconds)
5400000 (milliseconds)
5400000 (milliseconds)
5400000 (milliseconds)
These settings are located at: ../*ora/iAS/Apache/Jserv/etc
JServ Timeout is specified by the value of the property session.timeout in the JServ configuration file, and represents the number of milliseconds to wait before ending an idle JServ session (the default is 30 minutes).  This timeout is used by products based on Oracle Applications Framework (OAF).  

1.       What happens when a user logs in to Ebiz ?
a.     EBS server generates a new session, which is not yet stored in the database, and
b.    encrypted version of the session id is passed back to the browser in a cookie with key-name JSESSIONID. HTTP response header looks something like,
c.    Browser uses this JSESSIONID for all further interactions with EBS server. You can easily see this, if you monitor HTTP traffic between your machine and the EBS server.
d.    Browser sends a POST request to EBS server along with cookie information which it got from the server in the first place. First and foremost, an entry is created in FND_LOGINS table.
e.    select * from fnd_logins where user_id =( select user_id from fnd_user where user_name='SRIDHAR' ) order by start_time desc;

f.    FND_LOGINS table has following important columns like LOGIN_ID, START_TIME and END_TIME. LOGIN_ID is auto generated and unique. There could be many LOGIN_IDs associated with a single USER_ID. Even if same user logs onto EBS server from the same machine using two browser instances, two rows in FND_LOGINS table would get generated, each with different LOGIN_ID.START_TIME is the time when user logs in and END_TIME is updated only if user explicitly logs out from the application.
g.    Next an entry is made into ICX_SESSIONS table. ICX_SESSIONS and FND_LOGINS tables are are correlated by the column LOGIN_ID. ICX_SESSIONS has session id whose encrypted version was sent out by EBS server in the first place when user brings up EBS login page.
h.    select * from icx_sessions where user_id =( select user_id from fnd_user where user_name='SRIDHAR' ) ;


i.    When user logs out from the application, with JSESSIONID passed as part of the cookie, EBS figures out from the corresponding row in ICX_SESSIONS table, gets LOGIN_ID, gets corresponding entry from FND_LOGINS table and updates END_TIME and which basically means session has been terminated
j.    Before Logout

 k.    After Logout

Post a Comment