![]() |
JavaTM 2 SDK, Enterprise Edition 1.3.1 Release Notes |
1. Read the Installation Instructions to find out how to set the J2EE_HOME
and JAVA_HOME
environment variables. The Installation Instructions are on our web site and may be reached by a link on the J2EE SDK download page.
2. Install the software that the JavaTM 2 SDK, Enterprise Edition relies on. See the Required Software section of this document.
3. Go to the J2EE Tutorial to learn how to use the J2EE SDK. The J2EE Tutorial is found at:
http://java.sun.com/j2ee/tutorial/index.html
verifier
getHandle
method for entity beans.
For more information on JDBC technology, see the JDBC Data Access API web page. For a list of links to driver vendors, see the JDBC Technology Drivers page.
After you've installed your driver, follow the instructions in the JDBC Drivers section of the Configuration Guide to configure the driver for use with the J2EE SDK. If you are using the Cloudscape DBMS included in this release, you do not have to configure its driver.
See the section New Treatment of Non-XA Data Transactions, for additional driver related information.
The j2eeadmin
utility adds JDBC drivers, JMS destinations, and connection factories for various resources.
The deploytool
utility packages J2EE components and deploys J2EE applications. In the 1.3.1 release it receives an enhanced update function and intelligent field completion.
The keytool
utility creates public and private keys and generates X509 self-signed certificates. The J2EE SDK version is a wrapper for the J2SE SDK version, but adds an option for the format conversion of PKCS12 certificates.
The realmtool
utility manages users for the J2EE server.
The verifier
utility validates J2EE component files.
The packager
utility packages J2EE components.
The cleanup
utility deletes all deployed J2EE applications.
This release of the J2EE SDK requires the versions of the J2SE SDK listed in the following table:
Note: Versions of the J2SE SDK not listed in the preceding table have not been tested and are not supported. For example, the J2SE SDK v. 1.2 will not work with this release of the J2EE SDK.
stmt.executeUpdate
call will fail:You may be able to get around this limitation by trying the following approaches:String query = "SELECT DEPTNO FROM DEPT . . ."; String update = "UPDATE EMPLOYEE . . ."; ResultSet rs = stmt.executeQuery(query); while (rs.next()) { String s = rs.getString("DEPTNO"); // The following statement will FAIL: stmt.executeUpdate(update); . . . }
1. Use a stored procedure that contains the same SQL calls.
2. Substitute an iteration with a single SQL statement that contains a subquery. Here's an example:
3. Call another method that issues the second SQL statement. The method must use the RequiresNew transaction attribute. If you try this approach, you should be aware that the second SQL statement is executed in another transaction. Therefore, if the second transaction fails, you need to mark the first transaction for rollback.String update = "UPDATE EMPLOYEE SET DEPTNO = (SELECT DEPTNO FROM DEPT WHERE LOC = `ATLANTA') WHERE TITLE = `ENGINEER'";
In the J2SE 1.3.1 softeare, an OutOfMemoryError
can result when a very large number of classes are loaded by the Java virtual machine, even when there are free spaces on the Java heap. Workaround: Edit bin/setenv.sh
or bin/setenv.bat
to add the following option to the JAVACMD
variable:
See also-XX:MaxPermSize=256M
http://developer.java.sun.com/developer/bugParade/bugs/4390238
j2ee.jar
file of the J2EE SDK already has the RMI-IIOP and JAXP classes. Workaround: Use a fresh J2SE installation without the standard extensions.Note: The Tomcat implementation in the J2EE SDK might be slightly different from the version of Tomcat 4.0.2 distributed separately because of different release schedules. For more information about Tomcat, please see http://jakarta.apache.org/.
To fix this problem, change the default port numbers in thej2ee -verbose . . . J2EE server Listen Port: = 1050 java.lang.RuntimeException: Could not initialize j2ee server. Possible cause could be another instance of the server already running. . . .
$J2EE_HOME/config/orb.properties
file. For example, you can add a zero to each port number in the orb.properties
file:port=10590 host=localhost
To communicate with an enterprise bean running on the J2EE SDK server, the client running on an application server provided by another vendor must have the j2ee-ri-svc.jar
file in its class path.
A client is running on the J2EE SDK server doe not need the j2ee-ri-svc.jar
file to communicate with an enterprise bean on an application server provided by another vendor.
The j2ee-ri-svc.jar
file is located in the lib
directory of the J2EE SDK installation. It contains portable system value classes such as implementations of javax.ejb.Handle
and javax. ejb.EJBMetaData
. These implementations are specific to the J2EE SDK.
For more information on EJB container interoperability, please refer to section 19.2 of the Enterprise JavaBeans 2.0 specifications. A link to the specifications may be found on the J2EE SDK download page.
Note that the persistence manager in the J2EE SDK only supports forward mapping of a CMP 2.0 abstract schema to a relational database. Using the J2EE SDK's tools, it is not possible to reverse map from existing database tables to a CMP 2.0 abstract schema.
deploytool
has an enhanced update function. The update function now locates files for inclusion in the deployed application by using search paths that are provided by the user. If some files are not found, the user is shown a split screen with the found files listed in the upper half of the Entries Changed dialog. Clicking on a file in the list displays the path used for locating the file. The user can verify that the intended file has been found, or edit the search path to bring in the correct file. Files that have not been found are listed in the lower half of the dialog, under Entries Not Found on Diskn. Files can be moved into the found category by editing the search path so that they will be located by the program.
The screen for editing search paths is accessed by clicking the Edit Path button on the dialog.
deploytool
has been improved in other, less visible ways. Intelligent field completion has been enhanced with improved filtering of local/remote interfaces and with the automatic entry of primary key classes for Container Managed Persistence (CMP) 2.0.Note ¯ Database drivers that support XA data-sources allow you to connect to multiple databases and to distribute transactions across machines or processes. JDBC 1.0 drivers do not support XA data sources. Some JDBC 2.0 drivers support XA data-sources and some do not. See the Configuration Guide for information about the installation of XA and non-XA drivers.
A local transaction is restricted to the use of exactly one non-XA data-source and to transactions that are completed within one Java virtual machine. Thus, a global transaction is not started and there is no need to go to the JTS layer. The resulting optimization results in a vast improvement in performance of begin/commit operations. With a local transaction there is no need for two-phase commits. The use of multiple non-XA data-sources or multiple Java virtual machines would require two-phase commits.
Breaking out local transactions will allow many uses of non-XA data-sources to be optimized. When two non-XA data sources are needed, they can be used by declaring them to be XA data sources in the J2EE SDK's resource.properties
file.
If more than one resource is used in a transaction, non-XA data sources must not be used. (Examples of resources are relational databases accessed through the JDBC API, JMS queues and topics, and EISs accessed through the J2EE Connector architecture.) Instead, all resources must support XA transactions. It is illegal to use more than one non-XA data source in the same transaction.
Previously, the J2EE SDK committed multiple non-XA data-sources without doing a two-phase commit. This non-compliant procedure could result in a loss or corruption of data.
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.