Developing and Deploying Java Applications within the Oracle 8i JVM

Best Practices for Productivity and Performance

Hal Hildebrand

Consulting MTSHal.Hildebrand@oracle.com

Who’s Afraid of the 8.i JVM?An irreverent introduction to the Oracle 8i Java Server

Architecture

Overview

� To write applications for a server, you mustunderstand the way the server is architected.

� Like PL/SQL, Java code that runs in the Oracle8iJVM is running in a database session.

� The Oracle Oracle8i JVM has two major modes ofoperation: Java stored procedures and Presentations.

Java is a Portable Language andthe Oracle8i JVM is a ServerPlatform� Java is designed to be a portable language.� Countless product managers have performed blood

rituals and have made dark pacts with beings tooterrible to mention to ensure that Java runs on theirtop tier platforms for their products.

� The Oracle8i JVM is first and foremost, a Java serverarchitecture. It is a deployment server platform.

Java Runs In Every Tier

� At the 10,000-foot level, the story is that you canwrite your entire application in Java, and componentarchitectures allow you to choose where to run eachpiece of the application.

� Naturally, partitioning of the application is critical tothe performance of the application. Poorlypartitioned applications tend to run poorly.Applications that are sensitive to the partitioningarchitecture tend to run faster, be more reliable, andin general, are easier to maintain.

Java in the Client

� This tier was the first to run Java. Besides theoccasional animated elves, this tier has been ceded tothe web browser, and to the multi-media plugins inthose web browsers. JavaScript is still useful toaccomplish the odd verification task, and to make upfor dynamic programming holes in HTML. Butother than that…

Java in the Middle Tier

� This tier quickly became the focus of all who wouldtap into the fire hydrants of money that the Internethas unleashed - at least those of the WORA religion.

� But, Java alone does not a server make. Java is ageneral-purpose language, and like the Swiss armyknife, pretty much good for any programmingproblem you may find yourself in. As more andmore Java middle tier servers came on line (and Sunsaw the open source server market slipping awaywithout their mark), a locust-like swarm of servercomponent architectures appeared on the scene.

Java in the Database Server

� One of the sub-architectures of the Oracle8i JVM isthe Java stored procedure. Like PL/SQL, Java canbe used as a stored procedure language.

� With the inclusion of Java as a stored procedureimplementation language, one of the last holes inthe WORA architecture is closed, allowingapplication developers the flexibility of partitioningtheir applications (within reason) to run onanywhere on the landscape consisting of themultitude of tiers that constitute today’s applicationenvironment.

No More Tiers

� The Oracle RDBMS environment includes aTransaction Processor (TP)monitor environment,which is quite useful. This environment is the Multi-Threaded Server (MTS) architecture of Oracle8i. TPmonitors, the Holy Grail that cleansed all sin in the1980’s, are the model for today’s server componentarchitectures. Regardless of what they say in public,server vendors benchmark using TP monitors.

Data Drives Location

� Anyone who has ever developed a Model ViewController application, which requires an unholyquantity of getter and setter methods, is painfullyaware of this “law”.

� Thus, any non-trivial application is partitioned intomultiple address spaces (which are what Java VMsrepresent). Because of this, all non-trivial applicationarchitectures will want to minimize communicationcontent between Java VMs – especially thecommunication that crosses machine boundaries.

Clusters of SMPs are Easier to Managethan Clusters of Single ProcessorMachines

� Clusters of Symmetric Multi-Processors (SMPs) provideprovably better access in architectures that have many clientsaccessing a transactional store of slow data.

� Coordinating amongst friends to whom you can talk directlyis always easier than talking to friends via the U.S. Mail.There’s a non-negligible time lag that cannot be ignored indistributed communication architectures, a time lag thatsignificantly dominates the semantics of any distributedarchitecture.

SMPs vs. Single Processors

� Multiple processes on multiple machines areinherently harder to manage than multiple processeson a single machine. Multiple processes on a singlemachine can use shared memory semantics and usesimple semaphores for synchronization. They arerelatively easy to manage because they share acommon context, which can be shared betweenthem.

SMPs vs. Single Processors

� Mapping processes to machines raises thearchitecture to the massively parallel level. Nolonger do large grained processes dominant thearchitecture. A multitude of fine-grained processesdominate the system – communication becomesking.

All of Computing is an Exercisein Caching� Or to put it another way, a pool is so fundamental as

to almost be ignored when designing large-scaleserver architectures. The laws of large numbers ofclients tells us (at least empirically) that ninetypercent of the clients are likely quiescent at any giventime. Thus, we can design the system such that, atany given time, only ten percent of the number ofclients actually requires the host machine’s processortime.

Server Components are Resourcesto be Managed� One of the ways of using the Oracle8i JVM is to

treat server component models as resources to bescheduled like traditional TP monitors wouldschedule a traditional client-server application.

� If you can map the concept of a database call to theserver component model, then the underlying TPmonitor of the server can deal with making clientcalls scale.

Common Oracle8i JVMArchitecture� First, we’ll present the architecture of the Oracle8i

JVM that is common to both modes of operation.This will lay the groundwork for understanding thespecialized operating environments of the Javastored procedure and Java presentation architectures.

A Session Based Architecture

� The architecture of the JVM in Oracle8i is based onthe RDBMS session model. Sessions are privateaddress spaces that clients have exclusive access to.They are not shared with any other client, althoughthey may be serially re-used between clients (whenused in a pooling model, for example). Sessions areisolated from each other. This means that theactions of one client cannot impact any other client.All interaction between clients is done through thedatabase itself, using transactional semantics.

8.i Runs Java in the SQLProcess Address Space� The 8i server does not implement this model by

making callouts from the SQL server process to anexternal Java process. In stark contrast, the Oracle8iJVM model leverages the session itself to create avirtual Java VM on a session-by-session basis. Thesevirtual Java VMs run in the same address space asSQL and PL/SQL – i.e. the session itself. Thismeans that from the client session viewpoint, theclient is the only code running in the Java VM.

Isn’t That Expensive?

� Now, your first reaction to this statement is likely tobe “gee, if I have a Java VM per client, then isn’t thatreally expensive?”. The answer is a resounding No!The 8i JVM is a custom written Java VM which isarchitected, from the very beginning, using sharedmemory architecture. Without getting too technical,what this means is that all clients share the read onlystatic portion of the Java VM.

A Shared Memory Architecture

� All the class meta information, including theconstant pool data, method bytecodes, etc., areshared between all clients in the same databaseinstance.

Call Based Memory Management

� The Oracle8i JVM uses the call as a fundamental organizingprincipal. Like PL/SQL, Java threads are only active duringthe duration of the database call. Without going into toomuch detail, calls can be recursive; i.e., a call to the databasecan result in a recursive call to the same database, in the samesession.

� The database call is easily understood as theexecution of a java.sql.Statement. The SQLstatement may, when talking JDBC to the 8iserver, result in the execution of PL/SQL, or a Javastored procedure.

The Top Level Call

� The first call to the database is known as the Top-Level call. In the Java stored procedure model, thetop-level call is defined by SQL. The Oracle8i JVMalso sports a model where the top-level call isdefined by Java. These two different modes ofoperation are discussed later in the paper.

Schema Based Class Organization

� Java classes in 8i are not stored in the file system liketraditional Java VMs. The actual class and sourcebits are stored in the database system the same waythat PL/SQL packages are stored. Although a deeptechnical discussion of exactly how this is done isbeyond the scope of this paper, it is sufficient to saythat Java classes, sources, and resources are databaseobjects, and as such are listed in the Oracle tableUSER_OBJECTS.

An Advanced SecurityEnvironment� As all Java is run inside an 8i server session, there is a strong

notion of identity inherent in the environment� Login User

– As the name implies, it is the user that logs in to the server,establishing the base identity under which all SQL, PL/SQL andJava is executed.

– Effective User– The effective user of a session is the dynamic identity of a session.

The dynamic identity of a session is changed by running definer’srights code – either Java or PL/SQL

Efficient Access to the UnderlyingRDBMS� Because the Java is running directly in the database

session, access to the underlying SQL is available tothe Java code through JDBC, without logging in –the session is already established! This connection tothe SQL engine is a distinguished JDBC connection,obtained through either a JDBC URL, or throughstatic methods on the Oracle-specific JDBC driverclasses.

A Sophisticated Run-As Capability� Java code in the 8.i environment has a run-as capability that

has no analogy in other Java VMs. Java classes can beoptionally made definer’s rights – or bound. As mentionedabove, definer’s rights Java classes will change the effectiveidentity of the session. By executing definer’s rights classes,the effective user of the session can be temporarily changed.For example, suppose class B is definer’s rights code, wherethe defining schema is SYS. When methods in class B areexecuted, the identity of the session will become SYS. Thismeans that all SQL executed by JDBC in this session, usingthe default connection, will be executing as SYS – allunqualified object references will be resolved relative to theSYS schema, and permissions will be checked against the SYSschema.

Integrated Java 1.2 Security Model

� A new, finer grained security model was introducedin Java 1.2. This security model defines the notionof a code base, and permissions, which are granted,to the code base. Although a complete discussion ofthe 1.2 Java security model is outside the scope ofthis paper, suffice it to say that the permissions atany point of execution are the intersection of thecode bases on the thread’s execution stack. Thismeans that different code bases can limit theeffective permissions, but never extend them.

Tying Permissions to ClassSchema� In the 8.i Java VM, the code base of a Java class is

considered to be the defining schema of the Javaclass. The 8.i server environment includes a systemthat allows administrators and users to grant ordisallow permissions on a schema and role basis.

Effect of Definer’s Rights Class

� The effective user and login user of the sessioninteract with the Java permission model in astraightforward way. When running definer’s rightscode, it is equivalent to the Java mechanism,java.security.AccessController.doPrivileged(). Thishas the effect of trimming off the permissions stackat the definer’s rights code.

Java Stored ProcedureArchitecture� Java stored procedures are very similar to PL/SQL

in their interface with SQL. They are designed to becallable from SQL, so this is no surprise. The Javastored procedure has a PL/SQL wrapper, or callspec, that defines how the external function orprocedure is typed, and which Java static methodimplementation is used.

Embedded Java VM

� The Java stored procedure execution environment isone of an embedded Java VM. This means that theSQL call to the database is the top-level entry pointin the session, just as it is in PL/SQL execution.Thus, in the stored procedure world, all Javaexecution happens as a result of SQL execution.

Java Stored Procedure Lifecycle

� VM Startup� Top Level and Re-entrant Calls� Java State Between Calls� VM Shut Down

VM Startup

� The first time Java is called, either directly as aPL/SQL wrapped function or procedure, orindirectly, as a trigger, the Java VM is started up.Unlike a traditional Java VM, this is not in responseto a top-level call to the main() method. Ratherentry into the Java VM is through any public staticmethod that is published via a PL/SQL wrapper.

Top Level and Re-entrant Calls

� Because Java stored procedures can perform SQL,further stored procedures may be called as a result ofexecuting SQL. This means that Java can berecursively invoked. When Java is recursivelyinvoked, the same Java VM is used, and the Javacode run has access to the same Java state as theoriginating call. This means that Java statemanipulated in the recursive procedure is visible tothe outer calls.

Java State Between Calls

� The only Java state maintained between calls is thestate that is rooted from the static variables of theactivated classes in the session. If a Java object isnot reachable via some route that is rooted in a staticvariable of some class, the object will be garbagecollected.

VM Shut Down

� Java is shut down when the SQL session is shut down. In theOracle8i JVM, the method java.lang.System.exit(int) is a no-op. Again, because Java is being called from a top-level SQLcall, no JSP should be terminating the session, as this causesinteresting problems with SQL clients. Naturally, there areways around this, the Oracle8i JVM environment providingmechanisms by which Java can shut down the session. Thesemechanisms should, of course, be used sparingly and onlywhen the effects are well understood by the application.

Java Stored Procedure SecurityEnvironment� Because the Java stored procedure is called from

SQL, the SQL client establishes the login user of thesession. Thus, the security environment is notestablished by the Java code, rather inherited fromthe SQL environment. However, as mentionedabove, definer’s rights Java code can change theeffective user of the session. Likewise, PL/SQLdefiner’s rights code that directly, or indirectly runs aJava stored procedure will determine the effectiveuser of the session when Java is entered.

SQL and Java Objects

� SQL does not have a notion of an object pointer.Thus, Java objects cannot be returned as the resultof a Java stored procedure.

� If objects are to be used between stored procedurecalls, they must be stored in a way reachable fromstatic class variables. In this way, Java storedprocedures can repeatedly operate on the same Javaobject instances.

Java Presentation Architecture

� Java is often billed as network language. A networklanguage relies, ultimately, on TCP/IP socketcommunications with the outside world. In additionto the Java Stored Procedure model, the Oracle8iJVM provides an event driven server model forinbound java.net.Socket interactions with externalclients.

TP Monitor Server Model

� Like the stored procedure model, the Presentationmodel is based on the same session oriented JavaVM. However, unlike the stored procedure model,the Presentation model is based on the use of MTS(not to be confused with the MicrosoftTransaction Service). While a full discussion ofthe 8i MTS server model is beyond the scope of thispaper, suffice it to say that MTS is essentially a built-in TP monitor for the 8i server.

Java is the Top Level Call

� The primary difference between the JSP model and thePresentation model is that Java, rather than SQL, is definingthe top-level call of the server. Because the Java Presentationmodel uses TCP/IP for the inbound socket model, it is moreflexible than the SQL model. For example, the JavaPresentation model allows sessions to have multiple inboundTCP/IP socket connections, as well as multiple outboundTCP/IP socket connections. Also, the session lifetime maybe independent of the existence of inbound connections tothe session. By contrast, the SQL session has only oneinbound connection from a single client. The SQL sessionlifetime is determined by the client connection lifetime.

Support for Multiple Protocols

� The Java Presentation server architecture uses thejava.net.Socket model for communication and cantherefore support protocols other than SQL*NETfor clients to communicate to the server. Protocolssuch as HTTP and CORBA (IIOP) provide accessto the Servlet 2.2 and EJB 1.1 component models.

� The support of advanced Java component modelsembedded in a TP monitor server environmentprovides a very scalable platform to host serverapplications.

Java Presentation Lifecycle

� Sessions running under the Java Presentation modelhave a similar lifecycle to normal SQL sessions. Theprimary difference being that from birth to death,they are controlled by Java code, rather than SQLinteraction with the client.

� Because protocols and component modelsimplemented in Java control the sessions, there is achicken and the egg problem. We can only run Javain a session, so we first need to have a session beforewe can execute Java.

Session Establishment

� Unlike SQL*NET, many Internet TCP/IPprotocols, such as HTTP do not have an intrinsicnotion of “logging in”. Other models, such asCORBA, have a notion in their security model, butimplement this using the underlying protocol itself.Because of this, a model must be created whichallows server code to run securely, establishing theclient’s identity.

Java Server Component Models

� Key to the TP monitor server architecture is thenotion of a server component. The server sidecomponent is an object that has narrowly definedboundaries. In essence, the server componentmodel is cleanly divided into the environment (theContainer) and the actual server object itself (theComponent).

Component Code is NotGeneral Purpose� Component code is clearly not general-purpose

code. Component models are designed to takeadvantage of certain environments. The container,by definition, imposes a set of ground rules that thecomponent must conform to. In essence, thecomponent is a resource that the container mustmanage.

Typical Metrics Which DefineComponent Resources� CPU� Object Memory� JDBC Statements� JDBC Connections� JDBC Transactions� Outbound TCP/IP Sockets

Typical Component SecurityNotions� Authorization� Run As Identity� Access Control� Security Impersonation

8.i JVM as a ComponentServer Platform� The Oracle8i JVM provides a unique server

environment, being embedded in a highly scalableRDBMS that already has strong notions of securityand resource management. Thus, it’s not surprisingto see TP monitor like semantics in the Java servercomponent models supported by the Oracle8i JVM.

EJB

� The Java Presentation architecture was initiallydeveloped to support EJB on the Oracle8i JVM.The semantics of session beans are very close to thesemantics of running in the session oriented VM.Because Java already executes in a secure serverenvironment, the security aspects of EJBs are easy tomap. The call oriented nature of the JVM mapsquite well to the call-oriented interface of sessionbeans

Servlets

� In Oracle8i Release 3, the Oracle8i JVM nowcontains a Servlet 2.2 compliant container –commonly known as the Oracle Servlet Engine (orOSE). As the Oracle8i JVM is a session orientedVM, it’s no surprise that the OSE is geared forsession-oriented interaction with HTTP clients.Through the use of an Apache module, mod_ose,stateless interaction with HTTP clients is efficient aswell.

Servlets Calling EJBs

� Servlets running in the OSE can directly invokeEJBs bound in the JNDI namespace, vastlyincreasing the performance and simplicity of usingEJBs from Servlet code.

� Because the OSE is running in the same advancedserver environment that the EJB container isrunning, the OSE can extend the Servlet 2.2 api toprovide advanced security and database interactions– the dream of every middle tier.

Oracle8i JVM Best Practices

� And finally, if you’ve followed this far, we come tothe distilled wisdom of several years programmingfor the Oracle8i JVM. The advice should certainlyseem common sense by now, having sloggedthrough all the previous information.

Treat Java Stored Procedures LikePL/SQL� You wouldn’t pop up a modal dialog in a PL/SQL

function, nor should you even consider it in a Javastored procedure. Because PL/SQL is a procedurallanguage, not an object oriented language, the Javastored procedure interface is procedurally oriented aswell. Do not assume that you have an Object type inSQL – the Java stored procedure interface isimplemented via static class methods and is limitedto SQL data types for parameter and return typedefinitions.

Understand the Session Model

� Live with it. Although it’s not the best model forevery piece of code, it is the best model for many kindsof code. The session model is fundamental to goodOracle8i JVM architectures. If you understand it,your code will prosper. Cross it, and you’ll bewondering why the performance of your applicationdoesn’t satisfy.

Single Client Per Session

� The essence of the session model is the single clientper session. You should slap yourself silly any timeyou find yourself fantasizing about serving multipleclients with a JVM session. Sessions are seriallyaccessed by clients, and so are not architected toefficiently multiplex simultaneous clients.

Sessions Can Be SeriallyReused� This is not to suggest that you can’t make effective stateless

use of the Oracle8i JVM. Like normal SQL sessions, a poolof 8i Java sessions can be serially reused among a number ofclients. This can be done using fundamentally the same toolsas pools of SQL sessions that run PL/SQL. For Servlets, youcan take advantage of the mod_ose stateless ServletContexts.For SQL clients, the interface is effectively PL/SQL,although CORBA connections to the Oracle8i JVM provideRMI communication interfaces to pools of EnterpriseJavaBeans.

Think Twice Before SpawningThreads� Really. Why do you want to do this? Ignore the

little devil on your shoulder and consult a goodfriend. Go to dinner. Have a relaxing evening in thehot tub. Forget all about it when you come back towork in the morning.

8.i JVM Threads are Non-Preemptively Scheduled� Seriously. Java Threads running in the 8i session are

not preemptively scheduled. This means that unlessthe Java code yields - i.e.java.lang.Thread.yield() – anotherjava.lang.Thread will not run. SQL thatexecutes in the session as a result of using the default(i.e. the jdbc:oracle:kprb: URL)java.sql.Connection is single threadedanyway. This means you can’t ever execute SQL inparallel from a Java session. This is because the SQLserver is single threaded on the session level.

Leverage Sophisticated Security

� One of the hardest things about middle tier Javacode is efficient security. Take advantage ofdefiner’s rights Java classes. They allow you tosecurely expose security-sensitive capabilitiesthrough Java APIs. Remember that the defaultJDBC connection of the session executes SQL as theeffective schema of the session.

Control Access to SecuritySensitive Java Classes� Control access to security-sensitive Java classes using the

execute rights associated with the Java classes. Althoughthese can seem to be a pain at times, the execute rights of theJava classes can be used to securely control access to sensitivecode. Get in the habit of understanding where functionalityis accessed and layer Java language security structures (privateand protected access, as well as package protected classes andinterfaces) on top of the airtight execute right mechanisms ofthe underlying RDBMS server.

In the End, Let Rationality BeYour Guide� Certainly, this is the most relevant of any suggestions the

author could provide the intrepid (and certainly patient)reader. There are only so many ways to boil water, and all ofthem require heat.

� When you partition your application, you must understandthe advantages and disadvantages of the servers that run yourcode. Choose the tier that runs your Java code wisely. TheOracle8i JVM provides new flexibility to the WORA religionby running Java in the database session itself.

� Nothing more. Nothing less.