| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server 3.1 Application Development Guide |
Part I Development Tasks and Tools
1. Setting Up a Development Environment
Part II Developing Applications and Application Components
6. Using the Java Persistence API
Additional Database Properties
Primary Key Generation Defaults
Changing the Persistence Provider
Restrictions and Optimizations
Using @OrderBy with a Shared Session Cache
Using BLOB or CLOB Types with the Inet Oraxo JDBC Driver
7. Developing Web Applications
8. Using Enterprise JavaBeans Technology
9. Using Container-Managed Persistence
12. Developing Lifecycle Listeners
13. Developing OSGi-enabled Java EE Applications
Part III Using Services and APIs
14. Using the JDBC API for Database Access
15. Using the Transaction Service
16. Using the Java Naming and Directory Interface
This section discusses restrictions and performance optimizations that affect using the Java Persistence API.
The following topics are addressed here:
EclipseLink features a number of enhancements for use with Oracle databases. These enhancements require classes from the Oracle JDBC driver JAR files to be visible to EclipseLink at runtime. If you place the JDBC driver JAR files in domain-dir/lib, the classes are not visible to GlassFish Server components, including EclipseLink.
If you are using an Oracle database, put JDBC driver JAR files in domain-dir/lib/ext instead. This ensures that the JDBC driver classes are visible to EclipseLink.
If you do not want to take advantage of Oracle-specific extensions from EclipseLink or you cannot put JDBC driver JAR files in domain-dir/lib/ext, set the eclipselink.target-database property to the value org.eclipse.persistence.platform.database.OraclePlatform. For more information about the eclipselink.target-database property, see Specifying the Database.
The Java Persistence API specification does not specify how the container and persistence provider should work together to serialize an extended persistence context. This also prevents successful serialization of a reference to an extended persistence context in a stateful session bean.
Even in a single-instance environment, if a stateful session bean is passivated, its extended persistence context could be lost when the stateful session bean is activated.
Therefore, in GlassFish Server, a stateful session bean with an extended persistence context is never passivated and cannot be failed over.
Setting @OrderBy on a ManyToMany or OneToMany relationship field in which a List represents the Many side doesn't work if the session cache is shared. Use one of the following workarounds:
Have the application maintain the order so the List is cached properly.
Refresh the session cache using EntityManager.refresh() if you don't want to maintain the order during creation or modification of the List.
Disable session cache sharing in persistence.xml as follows:
<property name="eclipselink.cache.shared.default" value="false"/>
To use BLOB or CLOB data types larger than 4 KB for persistence using the Inet Oraxo JDBC Driver for Oracle Databases, you must set the database's streamstolob property value to true.
Mapping references to column or table names must be in accordance with the expected column or table name case, and ensuring this is the programmer's responsibility. If column or table names are not explicitly specified for a field or entity, the GlassFish Server uses upper case column names by default, so any mapping references to the column or table names must be in upper case. If column or table names are explicitly specified, the case of all mapping references to the column or table names must be in accordance with the case used in the specified names.
The following are examples of how case sensitivity affects mapping elements that refer to columns or tables. Programmers must keep case sensitivity in mind when writing these mappings.
If column names are not explicitly specified on a field, unique constraints and foreign key mappings must be specified using uppercase references. For example:
@Table(name="Department", uniqueConstraints={ @UniqueConstraint ( columnNames= { "DEPTNAME" } ) } )
The other way to handle this is by specifying explicit column names for each field with the required case. For example:
@Table(name="Department", uniqueConstraints={ @UniqueConstraint ( columnNames= { "deptName" } ) } )
public class Department{ @Column(name="deptName") private String deptName; }
Otherwise, the ALTER TABLE statement generated by the GlassFish Server uses the incorrect case, and the creation of the unique constraint fails.
Use @OneToMany(mappedBy="COMPANY") or specify an explicit column name for the Company field on the Many side of the relationship.
Use the following elements:
<sql-result-set-mapping name="SRSMName" > <entity-result entity-class="entities.someEntity" /> <column-result name="UPPERCASECOLUMNNAME" /> </sql-result-set-mapping>
Or specify an explicit column name for the upperCaseColumnName field.
Column or table names specified in SQL queries must be in accordance with the expected case. For example, MySQL requires column names in the SELECT clause of JDBC queries to be uppercase, while PostgreSQL and Sybase require table names to be uppercase in all JDBC queries.
PostgreSQL stores column and table names in lower case. JDBC queries on PostgreSQL retrieve column or table names in lowercase unless the names are quoted. For example:
use aliases Select m.ID AS \"ID\" from Department m
Use the backslash as an escape character in the class file, but not in the persistence.xml file.
If a finder method with an input greater than 255 characters is executed and the primary key column is mapped to a VARCHAR column, Sybase attempts to convert type VARCHAR to type TEXT and generates the following error:
com.sybase.jdbc2.jdbc.SybSQLException: Implicit conversion from datatype 'TEXT' to 'VARCHAR' is not allowed. Use the CONVERT function to run this query.
To avoid this error, make sure the finder method input is less than 255 characters.
The following restrictions apply when you use a MySQL database with the GlassFish Server for persistence.
MySQL treats int1 and int2 as reserved words. If you want to define int1 and int2 as fields in your table, use `int1` and `int2` field names in your SQL file.
When VARCHAR fields get truncated, a warning is displayed instead of an error. To get an error message, start the MySQL database in strict SQL mode.
The order of fields in a foreign key index must match the order in the explicitly created index on the primary table.
The CREATE TABLE syntax in the SQL file must end with the following line.
) Engine=InnoDB;
InnoDB provides MySQL with a transaction-safe (ACID compliant) storage engine having commit, rollback, and crash recovery capabilities.
For a FLOAT type field, the correct precision must be defined. By default, MySQL uses four bytes to store a FLOAT type that does not have an explicit precision definition. For example, this causes a number such as 12345.67890123 to be rounded off to 12345.7 during an INSERT. To prevent this, specify FLOAT(10,2) in the DDL file, which forces the database to use an eight-byte double-precision column. For more information, see http://dev.mysql.com/doc/mysql/en/numeric-types.html.
To use || as the string concatenation symbol, start the MySQL server with the --sql-mode="PIPES_AS_CONCAT" option. For more information, see http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html and http://dev.mysql.com/doc/mysql/en/ansi-mode.html.
MySQL always starts a new connection when autoCommit==true is set. This ensures that each SQL statement forms a single transaction on its own. If you try to rollback or commit an SQL statement, you get an error message.
javax.transaction.SystemException: java.sql.SQLException: Can't call rollback when autocommit=true
javax.transaction.SystemException: java.sql.SQLException: Error open transaction is not closed
To resolve this issue, add relaxAutoCommit=true to the JDBC URL. For more information, see http://forums.mysql.com/read.php?39,31326,31404.
MySQL does not allow a DELETE on a row that contains a reference to itself. Here is an example that illustrates the issue.
create table EMPLOYEE (
empId int NOT NULL,
salary float(25,2) NULL,
mgrId int NULL,
PRIMARY KEY (empId),
FOREIGN KEY (mgrId) REFERENCES EMPLOYEE (empId)
) ENGINE=InnoDB;
insert into Employee values (1, 1234.34, 1);
delete from Employee where empId = 1;
This example fails with the following error message.
ERROR 1217 (23000): Cannot delete or update a parent row: a foreign key constraint fails
To resolve this issue, change the table creation script to the following:
create table EMPLOYEE (
empId int NOT NULL,
salary float(25,2) NULL,
mgrId int NULL,
PRIMARY KEY (empId),
FOREIGN KEY (mgrId) REFERENCES EMPLOYEE (empId)
ON DELETE SET NULL
) ENGINE=InnoDB;
insert into Employee values (1, 1234.34, 1);
delete from Employee where empId = 1;
This can be done only if the foreign key field is allowed to be null. For more information, see http://dev.mysql.com/doc/mysql/en/innodb-foreign-key-constraints.html.
|