At the heart of the Java platform lies the Java Virtual Machine, or JVM. Most programming languages compile source code directly into machine code, suitable for execution on particular microprocessor architecture. The difference with Java is that it uses byte code - a special type of machine code.Java byte code executes on a special type of microprocessor. Strangely enough, there wasn't a hardware implementation of this microprocessor available when Java was first released. Instead, the processor architecture is emulated by what is known as a "virtual machine". This virtual machine is an emulation of a real Java processor - a machine within a machine. The only difference is that the virtual machine isn't running on a CPU - it is being emulated on the CPU of the host machine.
The Java Virtual Machine is responsible for interpreting Java byte code, and translating this into actions or operating system calls. For example, a request to establish a socket connection to a remote machine will involve an operating system call. Different operating systems handle sockets in different ways - but the programmer doesn't need to worry about such details. It is the responsibility of the JVM to handle these translations, so that the operating system and CPU architecture on which Java software is running is completely irrelevant to the developer.
The Java Virtual Machine forms part of a large system, the Java Runtime Environment (JRE). Each operating system and CPU architecture requires a different JRE. The JRE comprises a set of base classes, which are an implementation of the base Java API, as well as a JVM. The portability of Java comes from implementations on a variety of CPUs and architectures. Without an available JRE for a given environment, it is impossible to run Java software.
Differences between JVM implementations
Though implementations of Java Virtual Machines are designed to be compatible, no two JVMs are exactly alike. For example, garbage collection algorithms vary between one JVM and another, so it becomes impossible to know exactly when memory will be reclaimed. The thread scheduling algorithms are different between one JVM and another (based in part on the underlying operating system), so that it is impossible to accurately predict when one thread will be executed over another.
Initially, this is a cause for concern from programmers new to the Java language. However, it actually has very little practical bearing on Java development. Such predictions are often dangerous to make, as thread scheduling and memory usage will vary between different hardware environments anyway. The power of Java comes from not being specific about the operating system and CPU architecture - to do so reduces the portability of software.
The Java Virtual Machine provides a platform-independent way of executing code, by abstracting the differences between operating systems and CPU architectures. Java Runtime Environments are available for a wide variety of hardware and software combinations, making Java a very portable language. Programmers can concentrate on writing software, without having to be concerned with how or where it will run. The idea of virtual machines is nothing new, but Java is the most widely used virtual machine used today. Thanks to the JVM, the dream of Write Once-Run Anywhere (WORA) software has become a reality.
HTTP SESSION
HttpSession is nothing but a java interface.The servlet container uses this interface to create a session between an HTTP client and an HTTP server. The session persists for a specified time period, across more than one connection or page request from the user. A session usually corresponds to one user, who may visit a site many times.
The server can maintain a session in many ways such as using cookies or rewriting URLs.
This interface allows servlets to View and manipulate information about a session, such as the session identifier, creation time, and last accessed time Bind objects to sessions, allowing user information to persist across multiple user connections.
ICX Session or Oracle Applications User Session
(Is it same as HTTP session/servelet session ?)
A http session or a servelet session usually corresponds to an application login/logout cycle, but that is not strictly true in the case of OA Framework applications.
When the user logs in to an OA Framework application, the OA Framework creates an AOL/J oracle.apps.fnd.common.WebAppsContext object and a browser session-based cookie that together keep track of key Oracle Applications context information like the current responsibility, organization id and various user attributes such as user name, user id, employee id and so on.
The cookie contains an encrypted key identifier for a session row stored in the Applications database.Specifically, this is the servlet session ID which, in its decrypted form, serves as the primary key in the ICX_SESSIONS table.(to get an idea do run Select * from ICX_SESSIONS , to get an exact idea of what information is stored in the table)The WebAppsContext retrieves this key value after each request and uses it to query the current session state.
The Oracle Applications user session or ICX SESSION is associated and not dependent with a servlet session, because , it has its own life cycle and time-out characteristics. Generally, the Oracle Applications user session has a longer life span than the servlet session. The servlet session should time-out sooner.
User session is dependent on following profiles:
a)ICX: Limit Time :Determines the maximum Oracle Applications user session length( in hours.
b)ICX:Session Timeout: Maximum idle time for the Oracle Applications user session specified in minutes).While servlet session timeout is purely dependent on setting in Apache Jserv session timeout setting. An Oracle Applications user session might be associated with multiple http servlet sessions. For example, the servlet session times out while the user takes a phone call in the middle of creating an OA Framework expense report, then resumes work before the Oracle Applications user session times out.If the Oracle Applications user session times out, as long as the user does not close the browser window (so the browser session-based cookie isn'tlost) and no one deletes the corresponding session row in the ICX_SESSIONS table, the user can resume her transaction at the point where he stopped working after being prompted to log back in. Although the best practice as per Oracle standards is to sync ICX_SESSION and servelet session,till passivation feature is implenented in Oracle Apps. Passivation is still not supported in 11i and 12i.
This is straight from metalink "The ICX: Session Timeout option sets the the maximum number of minutes to wait before invalidating an idle ICX Session. The default value is null. The web server session timeout value, or more appropriately the Apache Jserv Session value is used to specify the number of milliseconds to wait before invalidating an unused session. The default value is 1800000 or 30 minutes.We recommend that you set the ICX: Session Timeout and the Apache Jserv Session to be the same. It's better to be consistent and let the ICX session and the Apache Jserv (middle tier) session expire at the same time. If the ICX session expires before the Jserv session, the user will be presented with a login page even though the Jserv session is still active. If the user logs back in before the Jserv session expires, they will see the old state of their middle-tier transaction. This can be confusing, since from the point of view of the user there is no distinction between the ICX session and the Jserv session. We also recommend that you do not set the Apache Jserv Session timeout to be any higher than 30 minutes. Longer idle sessions will drain the JVM resources and can also cause out of memory errors. The session timeout for the webserver is specified via the following directive in the /Jserv/etc/zone.properties file.session. timeout=1800000"
