Under some configurations, users may encounter a warning log message in the log file such as the following one. The log message is harmless and indicates TopLink's search for the validation.xml file, which is defined in the JSR 303 Bean Validation specification. TopLink is able only to read the validation.xml from the filesystem, not from archives of any kind.

[WARNING] [] [org.eclipse.persistence.jaxb.BeanValidationHelper] [tid: [STANDBY].ExecuteThread: '35' for queue: 'weblogic.kernel.Default 
(self-tuning)'] [ecid: 8ee5cff5-3f55-4f1b-a389-4328958b1ee9-0000003d,0] [APP: 
webcenter] [partition-name: DOMAIN] [tenant-name: GLOBAL] Error parsing 
validation.xml[[
java.util.concurrent.ExecutionException: java.lang.IllegalArgumentException: 
URI scheme is not "file"

When using the TopLink Exalogic automated tuner, the oracle.toplink.exalogic.tuning.TuningAgent profiler is not enabled. The TuningAgent profiler has been disabled due to issues with stuck threads.

Use Oracle Enterprise Manager to set the EclipseLink log level; do not use the WLS System MBean Browser to complete this action.

A unit of work synchronized with a Java Transaction API (JTA) will throw an exception if it is released. If the current transaction requires its changes to not be persisted, the JTA transaction must be rolled back.

When in a container-demarcated transaction, call setRollbackOnly() on the EJB/session context:

@Stateless
public class MySessionBean
{    @Resource 
    SessionContext sc;
    
    public void someMethod()
    {
        ...
        sc.setRollbackOnly();
    }
}

When in a bean-demarcated transaction then you call rollback() on the UserTransaction obtained from the EJB/session context:

@Stateless
@TransactionManagement(TransactionManagementType.BEAN)
public class MySessionBean implements SomeInterface 
{
    @Resource
    SessionContext sc;
    
    public void someMethod() 
    {
        sc.getUserTransaction().begin();
        ...
        sc.getUserTransaction().rollback();
    }
} 

The returning policy, which allows values modified during INSERT and UPDATE to be returned and populated in cached objects, does not work in conjunction with numeric version optimistic locking for UPDATE. The value returned for all UPDATE operations is 1 and does not provide meaningful locking protection.

Do not use a returning policy for UPDATE in conjunction with numeric optimistic locking.

The use of returning policy for INSERT when using optimistic locking works correctly.

TopLink assumes that date and time information returned from the server will use Timestamp. If the JDBC driver returns a String for the current date, TopLink will throw an exception. This is the case when using a DB2 JDBC driver.

To work around this issue, consider using a driver that returns Timestamp (such as COM.ibm.db2.jdbc.app.DB2Driver) or change the policy to use local time instead of server time.

Another option is to use a query re-director on the ValueReadQuery used by the platform:

ValueReadQuery vrq = new ValueReadQuery(
    "SELECT to_char(sysdate, 'YYYY-MM-DD HH:MM:SS.SSSSS') FROM DUAL"
);
vrq.setRedirector(new TSQueryRedirector());
...
class TSQueryRedirector implements QueryRedirector 
{
    public Object invokeQuery(DatabaseQuery query, Record arguments, Session session)
    {
        String value = (String)session.executeQuery(query);
        return ConversionManager.getDefaultManager().convertObject(
            value, java.sql.Timestamp.class
        );
    }
}