This topic lists the current limitations associated with the Feature Pack for EJB 3.0.
The Feature Pack for EJB 3.0 is not supported for use in conjunction with other WebSphere products such as WebSphere Commerce Suite, WebSphere Process Server, or WebSphere Portal Server.
@Entity public class VersionedTimestampEntity { @Id private int id; @Version private java.sql.Timestamp version; .... }The provider updates the versioned field or property to a new value when an entity is written to the database. During an entity merge operation, this version field or property is examined by the persistence provider to determine if the entity being merged is a stale copy of the entity. An OptimisticLockException error is thrown if the operation failed because of the stale version condition.
The version field or property can be one of these types: int, Integer, short, Short, long, Long and Timestamp. When the Timestamp type is used as the version field or property, the application needs to be aware of the problematic behavior that exhibits because of the implementation precision used for creating the Timestamp object. A typical implementation uses the System.currentTimeMills() and the time precision of this method is platform-specific. For example, the precision is approximately 15 milliseconds and 2 milliseconds for Win32 and zOS respectively.
If an entity is persisted and then fetched and updated in a separate thread of execution, and then updated within this thread of execution within the precision window of the platform, the persistence provider is not able to detect the optimistic locking and optimistic concurrency condition. As a result, an OptimisticLockException may not occur and data integrity could be compromised.
The feature pack does not support Servlet 2.5 Web archive (WAR) files and Java Platform, Enterprise Edition 5 (Java EE 5) application client modules. However, the application server does support annotated injections for Servlet 2.4 WAR files and Java 2, Platform Enterprise Edition (J2EE) 1.4 application clients as a Common Annotations extension.
When an application executes the Java Persistence API (JPA) queries against an Informix® database, the database returns an SQL syntax error if the query employs table aliases for tables that are indexed. A workaround is to remove the index from the table.
When native SQL selections do not contain the select alias, you can use underscores in the column names and in Java field names. The native SQL query should reference the column names in the database and not the Java field names.
When the @Column annotation is removed, but your table columns names contain underscores, you must change the Java field names to underscore names that match the table column names. When the @Column annotation is missing, the default column name, for mapping purposes, is the Java field name. Thus, the column names in the table must match the Java field names.
When native SQL selections contain the select alias, according to JPA 1.0 specification, the @SqlResultSetMapping annotation should provide the mapping information.
@EJB(name="StatefulBean") public static DoubleAnnotationRemote bean1; @EJB(name="StatelessBean") public static void setbean1 (DoubleAnnotationRemote b) {bean1 = b;}
Extension | Default |
---|---|
Enable relationships for CMP 1.1 | Disabled |
Initialize EJB at application start (on specific beans) | Initialize at first usage |
Do not perform flush-before-find for CMP beans in an EJB module that is at the EJB 2.0 specification level or higher | Perform flush-before-find |
EJB container bean activation and load settings | Entity: Activate or passivate at Transaction Boundaries, Load at Activation (Option C); Stateful session: Activate and remain active until the ejbCache is full, deletion or timeout when you are using the distributed product and when not using clustered failover. Activate or passivate at Transaction Boundaries when you are using clustered failover, or always on the z/OS® product. |
Skip the ejbStore() call on CMP 2.x beans if the beans are not modified during transaction | Always call the ejbStore method |
Bean-specific transaction timeout | Server transaction timeout setting |
Local transaction settings (Boundary, Resolver, Unresolved_Action) | Boundary=BeanMethod, Resolver=Application, Unresolved_Action=Rollback |
What determines Internationalization locale: the caller or server | Server |
PersistenceManager data cache settings (Lifetime in cache, Lifetime in cache usage) | Data cache disabled |
Enable optimistic locking for CMP 1.1 | Disabled |
Method-level RunAs security identity | Deployment descriptor defined component level RunAs security identity |
Access intent for CMP 1.1 | Disabled |
Access intent for CMP 2.x (Read-read consistency checking, Partial update optimization, Batch deferred update optimization) | Disabled |
Isolation level for CMP 1.1 | Value defined on data source |
Stateful session bean timeout | 10 minutes of inactivity |
@OneToMany(cascade={CascadeType.ALL}, targetEntity=Rider.class, fetch=FetchType.EAGER) @JoinColumn (name="FK_ANNUITY_ID") public List getRiders() { return this.riders; }
The annotation that is above fails with ArgumentException. From Sun Microsystem’s JSR 220: Enterprise JavaBeans™, Version 3.0, Java Persistence API documentation: "The default schema-level mapping for unidirectional one-to-many relationships uses a join table, as described in Section 2.1.8.5. Unidirectional one-to-many relationships may be implemented using one-to-many foreign key mappings, however, such support is not required in this release. Applications that want to use a foreign key mapping strategy for one-to-many relationships should make these relationships bidirectional to ensure portability."
In addition, Table 8 on page 170 of JSR 220: Enterprise JavaBeans™, Version 3.0, Java Persistence API indicates that the JoinColumn annotation applies to one-to-one, Many-to-One, Many-to-Many relationships. The table does not mention the one-to-many relationships.
Because the Open JPA implementation does not provide this mapping in the current release, the mapping is behaving as expected.
<entity class="Annuity"> <attributes> <one-to-many name="riders" target-entity="Rider"> <join-column name="FK_ANNUITY_ID"/> <cascade> <cascade-all/> </cascade> </one-to-many> </attributes> </entity>
@OneToMany(cascade={CascadeType.ALL}, targetEntity=Rider.class, fetch=FetchType.EAGER) @JoinTable(name="ANNUITY_RIDER", joinColumns={@JoinColumn(name="FK_ANNUITY_ID")}, inverseJoinColumns={@JoinColumn(name="FK_RIDER_ID")})