readme_javavm.txt

Debian中文参考手册,系统介绍了Debian系统

correspond to the JDK default. If you have been using the presence of
"Oracle" in java.version to determine whether your code is running on
Oracle9i JVM as opposed to the client, then you should switch to testing
whether the oracle.jserver.version property is non-null.  (In release
8.1.5, the value of java.version was "Oracle Server 1.1.6". In release
8.1.6, 8.1.7 and 9.0.1 the value of java.version was "1.2.1").  The
property oracle.server.version is now deprecated.  It was set in 8.1.5,
8.1.6 and 8.1.7 for backward compatibility reasons only.

2.7  Java && in SQL*PLUS

SQL*PLUS interprets Java && as substitution variables.  The workaround
is to use loadjava to load source or to use loadjava to load binaries.
If you want to write Java source in SQL*Plus, you can "set define off"
first.

2.8  RMI and Sockets

Please refer to the Java Developer's Guide for information on O/S
Resources, Sockets, and RMI support in this release.  RMI is fully
supported, but you need to understand the implications of its use on
your ability to build scalable server applications.  Socket support
beyond end-of-call is discussed in the Java Developer's Guide.

2.9 Bug #895586 -- Multibyte Character Output Truncation at 255 Bytes

If you use dbms_java.set_output to redirect System.out.println() to
standard output, and the 255th byte is part of a multibyte character,
this character will be broken into 2 one byte characters in the
output.  The workaround is to break your output into smaller pieces.

2.10 Bug #1330979 -- Wrong Japanese error message returned in SQLException in Java

If you are using multi byte character set, the exception message
returned by java.sql.SQLException may be mangled.

2.11 Bug #1001690 -- Exception thrown when attaching JDB for debugging

When doing a call to DBMS_JAVA.START_DEBUGGING() and attaching with
JDB, a java.security.AccessControlException is thrown if you do not
have the required permissions. To grant these permissions to a user,
you need to do:

SQL> call dbms_java.grant_permission('SCOTT', 'SYS:oracle.aurora.security.JServerPermission', 'Debug', null);

To confirm that this permission is in effect, you can do:
SQL> select type_name, name, enabled from user_java_policy where type_name like '%JServerPermission%';

and should see Debug/ENABLED among the granted JServerPermission types.


2.12  Java Calling SQL and Vice Versa

Please refer to the JDBC README for details on limitations in "SQL
Call-in".  There are known problems with usage of some data types and
their translation between Java and SQL.  In general, these are not
JDBC problems, but are the responsibility of the Aurora runtime
machinery.  We have chosen to document the problems in the JDBC README
(ORACLE_HOME\jdbc\readme.txt) because JDBC users are the most likely
to encounter the problems.


2.13  Java and PL/SQL

Refer to the "Java Stored Procedures" documentation for details of
PL/SQL and Java interaction.  It is a known feature of call-spec
definition that there is no checking at definition time between the
method signature provided in the call-spec and the method which will
be invoked at runtime.  The design is such that mismatches are only
detected at runtime.


2.14 Examples
We provide numerous examples showing how to use Java Stored
Procedures.  The examples can be found under
ORACLE_HOME/javavm/demo. 

Before running these examples, you need to have the JDK commands for
java, javac in your PATH as decribed above in 3.13. You also need to
have ORACLE_HOME, CLASSPATH, JAVA_HOME, LD_LIBRARY_PATH set
correctly. Lastly, you should check the values for java_pool_size and
shared_poll_size, in the init.ora file. These should be at least 50mb
each.

Also note that within each Makefile, there are two different
classpaths defined - one for JDK1.1.x and one for JDK1.2. Before
running an example, you should edit the Makefile (or batchfiles on NT)
and verify that the relevant MAKE_CLASSPATH for your JDK installation
is uncommented.

All the samples should work, without any modifications, as described
in their individual readme. Please do read the readme, as some of the
preparations include things like creating a demo user "CLERK", before
being able to run. 


2.15 SSL Limitations

2.15.1 Using SSL client side authentication when making an SSL callout
from one server into another server is not supported in this release.

2.15.2 In this release, "SSL_CREDENTIAL" login is not supported. For
example, the code:

    env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.SSL_CREDENTIAL)

does not work and should be replaced with:

    env.put (Context.SECURITY_AUTHENTICATION, ServiceCtx.SSL_LOGIN)


3.  JAccelerator ("NComp"). Natively Compiled Java Code

This release contains all core Java classes, plus the JDBC, and SQLJ
Java classes in natively compiled form.  (Note: swing and awt classes,
which are included only for compatibility on the server, are not
natively compiled).  As described in the Java Developer's Guide, the
natively compiled code is dynamically opened at runtime using shared
object libraries from the ORACLE_HOME/javavm/admin directory.


3.1 Upgrade, Downgrade, Import, Export

Java code that you natively compile in this release will not be
automatically upgraded in future Oracle releases.  To move to a new
Oracle release, you will need to upgrade and then natively compile the
code again in the upgraded server.  Similarly, import and export of
Java code between Oracle databases does not include the natively
compiled form of your Java code.  In these cases, as long as the O/S
and platform are the same, you should redeploy the deployment jar
files that you created originally to install natively compiled Java
code in another location.


3.2 Security

Deployment of natively compiled code in the server is protected by a
Java privilege, as described in the documentation.  You should
understand that this privilege should only be granted when the party
installing or supplying the natively compiled code is well-known and
trusted.  The code generation process employed to produce the shared
libraries is provided by and tested extensively by Oracle; however,
unlike interpreted Java code and PL/SQL programs, native code is
executed from shared libraries that are dynamically opened at runtime.
The right to install such shared libraries should be closely
controlled.


3.3 Acceptable C Compiler Versions

Please review the Settings_<OperatingSystem>.properties file on your
platform to determine what C compiler Oracle has certified for
supported use with Oracle9i JVM Accelerator in this release.  Oracle has
continuing work to certify more C compilers against this and future
releases and will make such information available on Oracle TechNet on
an ongoing basis.


3.4 Known issues

3.4.1 JDK releases to avoid.  
If there is a choice, avoid, for the purpose of ncomping, Solaris
releases of JDK 1.1.7p, 1.2, 1.2.1p, 1.2.2_05a and 1.1.3 with native
threads.  We found problems using these releases, but have used 1.1.6
and 1.2.2_07 successfully.


3.4.2  C compiler out of memory during C compilation

During compilation of very large packages, C compilers may be getting
out of memory. You can switch to the non-bundling mode, compiling each
class separately, by omitting

makefile.maker = $(one.c.unit.per.dll.makefile.maker)

in files 
  javavm/jahome/Settings_solaris.properties
and
   javavm/jahome/Settings_sunos.properties


3.4.3  The flag -update does not work with jdk 1.1.x command-line option
-update of 'ncomp' does not work with jdk 1.1.x because the 'jar'
facility in these releases does not provide command-line option -u.


3.4.4 KNOWN BUG: Having a dot in directory name of deployment jar
aborts deployment

If you pass a full-path deployment jar name to deploync, you'll get
incorrect results if the directories in the path or the deployment jar
contain '.':

 deploync ... /foo.bar/mydepl.jar
 deploync ... /foo_bar/my.depl.jar

 Workaround(1) avoid using '.' in directories  and jar names, 
 Workaround(2): use -d:

 deploync ... -d /foo.bar mydepl.jar


3.4.5 Half of my package previously ncomped now is not!

If your app is in 2 jars, and for package P half of its classes are in
the first jar and half in the second, then after ncomping the second
jar you'll find the classes from the first jar un-ncomped. This is
because ncomp deploys dlls on a per-package basis. 

To avoid such situations, structure the source jars in such way that
all classes for a given package P are in a single jar. This also
offers the best possible performance.


3.4.6  All toplevels are in the same package UnnamedPackage!

Beware of toplevel classes: if you have a toplevel class X, previously
ncomped, and then you separately ncomped a toplevel class Y, X will
become un-ncomped. This is because all toplevel classes are considered
in a special package "UnnamedPackage".


3.4.7  "nothing needs ncomping because nothing is in package P"

If your source jar contains packages with non of classes present onto
the server, ncomp will report that each individual class is
NOT_FOUND_IN_SCHEMA yet each packages is ALREADY_NCOMPED:

NOT_FOUND_IN_SCHEMA oracle/aurora/mts/iiop/ORB
NOT_FOUND_IN_SCHEMA oracle/aurora/mts/iiop/SessIiopService
...
ALREADY_NCOMPED oracle/aurora/mts/iiop/

In this particular case the meaning of this ALREADY_NCOMPED is more
like "nothing needs ncomping because nothing is there"


3.4.8  ncomp says NEED_NCOMPING, and then it freezes?

After reporting a series of NEED_NCOMPING, ncomp keeps silent until it
creates the deployment jar and is ready to deploy. Depending on the
machine, this delay can look like a freeze. To see what is going on,
tail file ncomp.log. Another solution is to redirect the output to the
screen with -verbose.


3.4.9  Solaris-specific Settings_*.properties files

On Solaris we ship two platform-specific Settings_*.properties files.
  Settings_solaris.properties
and
  Settings_sunos.properties
File Settings_solaris.properties is picked up by JDKs 1.1.x, file
Settings_sunos.properties is picked up by JDKs 1.2.x


3.4.10  Managing filespace in javavm/admin

The 9.2.0 release of user interface to ncomp does not attempt to
manage the dlls in javavm/admin directory. Because dlls have unique
names, over time there javavm/admin might accumulate a number of
obsolete dlls.

For each given package in a given schema, only the most recently
deployed dll is in use. You can detect which dlls are in use by
analyzing table jaccelerator$dlls or by running the following script:

#!/bin/sh
# list of ncomp dlls in use

usage () {
  echo "libs used by ncomped classes foo/bar*"
  echo "usage: $0 foo/bar"
  exit 1
}

if [ $# -lt 1 ]; then  usage; fi

DIR=`dirname $0`

cat >$DIR/DLLsReport.java <<EOJAVA

package oracle.jaccelerator.utl;
import oracle.aurora.rdbms.Schema;
import oracle.aurora.rdbms.ClassHandle;
import oracle.aurora.rdbms.Handle;
import oracle.aurora.rdbms.ObjectTypeChangedException;
import oracle.sql.CHAR;

import java.io.*;
import java.util.Date;

import java.sql.*;
import oracle.jdbc.driver.*;

public class DLLsReport {
  public static String dll (String schemaAndName) 
    throws SQLException
  {
    int colonIdx = schemaAndName.indexOf(':');
    String name = schemaAndName.substring(colonIdx + 1);
    String schema = schemaAndName.substring(0, colonIdx);
    String  result = "bad handle";

    ClassHandle h = Handle.lookupClass(name, Schema.lookup(schema));
    if (h == null) {
      result = "null handle" + h;
    }
    else {
      result = h.getNcompDllNameAsCHAR().toString();
    }
    return result;
  }
}
EOJAVA

set -x

loadjava -oci8 -resolve -user internal/change_on_install  $DIR/DLLsReport.java

svrmgrl  <<EOI

connect internal/change_on_install

create or replace function isvnc_get_class_dll (pkg varchar2) return VARCHAR2 as
  language java name 'oracle.jaccelerator.utl.DLLsReport.dll(java.lang.String) return java.lang.String';
/
show errors;
select distinct isvnc_get_class_dll(OWNER || ':'  || dbms_java.longname(OBJECT_NAME)) from all_objects where OBJECT_TYPE = 'JAVA CLASS' and dbms_java.longname(OBJECT_NAME) like '$1%' ;

EOI


--  End of README  --