Select Page

Why should I properly close my Oracle E-Business Suite session?

R Harwood | | March 10, 2009

We’ve all been there before.  It’s noon, and you’re co-worker is telling you to tidy up – it’s time to go to lunch.  Your E-Business Suite session is idle, and in your haste you simply click the ‘X’ at the top of your browser.  You know it’s not the proper thing to do, but you’re not sure of the implications…. What happens when I close my session improperly?

First let’s define a proper application exit.

If you’re using an Oracle Forms responsibility, such as AP Manager or System Administrator, you’ll want to select focus on your window with the forms session and select the File->Exit Oracle Applications.  For jsp type applications, such as OAM or iExpense, you’ll want to click on the Logout link typically in the top right of the browser session.  

Given that, what are the incorrect ways to log out?

The answer is pretty much anything else.  Unless you close your session using an application exit command, you are probably closing the apps improperly.

Why should I care?

To appreciate this is to first understand the basics of what happens when the applications are given a proper, explicit indication you are leaving your Oracle application session.  In essence, all of your allocated resources are released.

In the database, your cursors are closed, your locks are relinquished, and uncommitted transactions are rolled back.

The application server is more involved:  For each Oracle forms session, there are individual f60webmx processes.  Upon a proper exit, these processes are gracefully and explicitly logged out of the database; local memory, processing, and network resources are released; finally, resources under /tmp including user export data, temporary space for long running queries, and temporary space for viewing log files and reports (has this ever filled up on you?) are released.

If shut down improperly, not only are these resources tied up longer than necessary, but orphaned f60webmx processes are notorious for occasionally growing into run-away processes that consume a huge portion of cpu.

When considering the application server resources for JServ or OC4J application sessions (iExpense for example), the issues are a little different.

These processes tend to be more memory-bound, as session state for each user is tracked in one of the large servlet processes.  If you’ve got a large data set cached, such as a listing of inventory items in iProcurement, this can weigh on your application server.  Logging off allows these processes to release these resources.  It also frees up your connection in the jdbc connection pool.

One approach to addressing this problem from a System Administrator perspective is setting the various configurable timeouts (see details on this below).  In my experience, the jsp servlets handle improper user logouts pretty well; however, your resources are not released for that timeout period (30 minutes maybe?).

The forms session have equivalent configuration, but the application server does not actually kill the f60webmx processes if the threshold is not met; the user is simply prompted to log in again.  This mechanism seems to address potential security concerns more than performance concerns.  The bottom line is these resources are still allocated.  Regardless of the technology, it is much better to deliberately log out of the applications.

In case you’re not familiar, Oracle provides the following summary of configuration parameters for Oracle E-Business Suite timeouts:

1) The ICX:Session Timeout profile is used to enforce inactivity timeout. If a user performs no Oracle Applications operation for a period longer than this timeout value (in minutes), the user’s application session is ended. When a user logs in to Release 11i, an ICX session is created and remains valid for the duration specified by this setting.

2) The ICX:Limit Time profile is used to specify the absolute maximum length of time (in hours) of any user’s Oracle Applications (ICX) session, whether active or inactive.

3) JTF_INACTIVE_SESSION_TIMEOUT affects CRM-based products only, and serves the same purpose as the ICX:Session Timeout profile. This profile exists for legacy reasons, and its value should be set to the same as ICX:Session Timeout.

4) JServ Timeout is specified by the value of the property session.timeout in the JServ configuration file zone.properties, 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).

Oracle EPM Cloud Vs. On-Premises: What’s the Difference?

EPM applications help measure the business performance. This post will help you choose the best EPM solutions for your organization’s needs and objectives.

Bobby Ellis | April 10, 2018

Hyperion Myth #9: SOX Audit Requests Are Time-consuming

With serious financial penalties, SOX audits can be intimidating — but they don’t have to be. Find out how you can use Datavail’s software to automatically prove SOX compliance.

Jonathan Berry | March 13, 2018

12c Upgrade Bug with SQL Tuning Advisor

This blog post outlines steps to take on Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.

Megan Elphingstone | March 22, 2017

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.

CONTACT US

Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.

EXPLORE JOBS