Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Java Virtual Machines

Oracle Application Server Tips by Burleson Consulting

A Java Virtual Machine is needed to execute compiled Java code or class files. When Java code is compiled, it creates a file of byte-code that ends in .class. The JVM interprets the byte-code when the application is run. This provides Java?s portability. Once Java code is compiled, it will operate on any platform that has a compatible JVM. It is the job of the JVM to take the byte-code in the class file, convert it into the local computer?s machine code, and execute it.

Figure 2: Executing Java on the Java Virtual Machine

Hence a Java application written on a Windows box will execute in the same way on a Solaris or Linux server. Java Virtual Machines also allow you to have nonhomogenous systems, with a powerful Solaris server hosting the database, two servers (one Linux and one Windows) hosting the application server, and clients using Netscape, Mozilla, and IE, all accessing the same Java application. Most Java tools (such as JDeveloper) are written in Java, and so the same program can run on multiple operating systems with pretty much the same appearance.

JVMs do much more than just execute class files. The JVM is responsible for security, allowing the application access only to those parts of the server allowed. This is why some applications have problems running in a browser. For example, the JVM that supports a browser ?assumes? an applet is untrustworthy and will not allow it to interface directly with operating system resources.

Enterprise JavaBeans

Enterprise JavaBeans often constitute the heart of an application running on Oracle Application Server 10g because EJBs contain the business logic of the application. They require a J2EE container to run, and they support distributed objects within the application. EJBs are constructed following a strict specification that insures EJBs work together within a large application. Applications find EJBs by using the JNDI service and interact with them through the container. By encapsulating business logic inside EJBs, you can distribute the application across different servers or have multiple copies of an EJB on different servers to load-balance the application. Although the discussion of writing EJBs is beyond the scope of this book, an introduction to the types of EJBs is needed. For additional information on creating EJBs, refer to the books identified at the beginning of this chapter.

There are three types of Enterprise JavaBeans: session, entity, and message-driven.

* Session EJB - These support a single client in the execution of a task. A session EJB exists only as long as that single client exists. It is not shared. A session EJB can be used to interact with a customer database to include executing dynamic or static SQL, or stored Java, or PL/SQL procedures or functions. Session EJBs are either stateless or stateful. The state of a bean is defined as the variable values it holds. A stateless session EJB implements business logic and does not maintain a state between calls. A stateful session EJB maintains a state (a set of variable definitions) between method calls. Methods can be used to change its state, and the new state will be maintained until it is changed again or it is removed from the container. Hence a stateful bean can support only one client, while a stateless bean can support multiple clients (one at a time).

* Entity EJB - These represent business data rather than business logic. An entity EJB represents data in a database, such as a customer order. Like data in a database, an entity bean can be shared by many clients and has a unique identifier called a primary key. Because an entity EJB?s state is based on some external persistent storage, its state does not change unless the data in the persistent storage changes. Entity beans normally connect to a database through the container. The container implements all the database connectivity. As with session EJBs, entity EJBs also come in two flavors?container managed or bean managed. Container managed persistence (CMP) is more popular because this type of EJB forces the container to handle the task of reading and writing object attributes back and forth to the database. The developer is normally not required to write any JDBC or SQL code. Bean managed EJBs, on the other hand, require that the developer handle the task of persisting object attributes to the database and then loading them back into the EJB when it is instantiated. This means writing all the SQL required via JDBC. This offers a great deal of flexibility, but it can be quite complex. It is easy to see why container managed persistence is the more popular choice today among Java developers. This will be discussed in detail in Chapter 8.

* Message-Driven EJB - These process JMS (Java Message Service) messages asynchronously. This differs from session EJBs, which will block while sending a request to another bean. Unlike session or entity EJBs, message-driven EJBs have no interfaces that clients can call directly.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.

If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational