Database Reference
In-Depth Information
when you have Java 1.7 or 1.8 on your workstation and you are using Oracle Database 12, you may still
be using an Oracle JVM based on Java 1.5 - the Oracle JVM gets that far behind.
In any case, Java 1.5 is what we needed in Oracle database to support our use of JCE. So we won't
criticize or lament.
A Separate JVM for Each Oracle Session
When you connect to Oracle database and use Java, you start a separate JVM for use only by your
session. You cannot share any Java objects or data with other running JVMs (Oracle sessions), unless you
store them in the database for others to query or hand the objects around through network port services
(e-mail, ftp, web, etc.)
When you disconnect from Oracle database, your Oracle session closes and the JVM is terminated. If
you immediately make a new connection to Oracle, you get a brand new JVM and nothing in your
previous JVM is retained or carried over to the new JVM.
This has repercussions for us. Primarily, since we are going to be generating cryptographic keys (you
might have already guessed that), we want to use them for a time to send encrypted data back and forth
before we close the connection to Oracle database and the keys are discarded. We could save the keys in
the database, or in what Oracle calls a wallet, which is basically a secure file on the hard drive of the
server and/or the client. But if they are stored anywhere, then we don't know who might get access to
them. No, what we will do is generate the keys on the fly and use them for a time, keeping our
connection open during the key exchange and multiple queries, and only close the connection when we
are done.
Oracle JVM Sandbox
We briefly discussed the Oracle JVM sandbox at the end of the last chapter. To recap that discussion, this
particular sandbox prevents the Java code in Oracle database from reading from/writing to the hard
drive; and from communicating on the network at all; however, it provides open access to the Oracle
database, limited by the Oracle privileges granted to the Oracle user who is executing the Java code, and
his roles. For example, if the
HR
user owns and is executing the Java stored procedure, it will have access
to all of the
HR
schema data.
Extended security privileges can be granted to Java code in Oracle database to perform functions
normally denied by the sandbox. These privileges are granted by administrative commands and are
stored in the database. Privilege grants can be broad or very granular. We will be using extended
privileges for Java code running in Oracle database in order to communicate to other machines over the
internet. You will see some very granular grants for those privileges when we get to Chapter 9.
Auto-Commit Disabled in the Oracle JVM
In SQL databases,
COMMIT
means to incorporate changes into the existing database. Until
COMMIT
is
executed, data updates are held in a cache. The session that made the updates can see the changes, but
everyone else sees the data as it existed before the updates. When the session executes
COMMIT
, everyone
can see the changes that were made. This is a powerful concept for transactions that have multiple steps.
In a single session, each step can be performed, and each successive step can base its actions on updates
already made in the session. When all the steps are completed, the session can issue a
COMMIT
, and all the
updates will be made to the existing database. However, if there is a problem in any later step, all the
completed steps can be
rolled back
(reversed) and not written to the existing database. You can see how
this might be handy if a bank is transferring money from you to me—they will take it from your account
and put it in my account. But if they have problems giving me your money, you want them to also
reverse the step where they took it from you.
