1. 技术文章
  2. Unexpected UnsupportedOperationException on Hibernate validation failure

Unexpected UnsupportedOperationException on Hibernate validation failure

由 痞子三分冷 提交于 2019-11-28 00:26:44

I ended up modifying the WebSphereExtendedJtaPlatform code according to the following link. I am so baffled why that class was essentially not implemented.

https://forum.hibernate.org/viewtopic.php?f=1&t=992310

I had the same problem on Websphere Liberty 16.0.0.4, and solved it with a change to persistence.xml:

<property name="hibernate.transaction.jta.platform" value="biz.bitech.hibernate.websphere.WebSphereJtaPlatform" />

The following class needs to be in the classpath along with the hibernate libs:

package biz.bitech.hibernate.websphere;

import javax.transaction.TransactionManager;
import javax.transaction.UserTransaction;

import com.ibm.tx.jta.TransactionManagerFactory;
import com.ibm.tx.jta.UserTransactionFactory;
import org.hibernate.engine.transaction.jta.platform.internal.AbstractJtaPlatform;

public class WebSphereJtaPlatform extends AbstractJtaPlatform {

    @Override
    protected TransactionManager locateTransactionManager() {
        return TransactionManagerFactory.getTransactionManager();
    }

    @Override
    protected UserTransaction locateUserTransaction() {
        return UserTransactionFactory.getUserTransaction();
    }
}

You create a new entity manager on each request using getEntityManager(). You should request (eg via dependency injection) the application wide persistence manager.

Please note that you are recieving the HHH000099 error from hibernate. This is due to the GeneratedValue returning null and when hibernate does an insert, it passes a null to your PK.

I take it that your ID is auto incremented withing the table. When you set Generated value to AUTO/TABLE/IDENTITY, Hibernate looks for the value in the table. It shouldnt be a problem if you persist the table.

I had a similar issue and all i did was make the column as insertable=false.

Hope that helps.

the code below is from hibernate-core 4.3.7.FINAL (SynchronizationCallbackCoordinatorNonTrackingImpl)

you will see a call to setRollbackOnly just before the exception is re-package and sent, for WebSphereExtendedJtaPlatform it simply throws an unsupported operation exception, which is what you see on the logs. At this point, as you never reach the point where your runtime exception is re-packaged, it is lost.

But somehow hibernate manages to log it out to the stdout, so you will find your SQL exception in your SystemOut.log file 

@Override
public void beforeCompletion() {
    LOG.trace( "Transaction before completion callback" );

    if ( !transactionCoordinator.isActive() ) {
        return;
    }

    boolean flush;
    try {
        final int status = transactionCoordinator.getTransactionContext().getTransactionEnvironment()
                .getJtaPlatform().getCurrentStatus();
        flush = managedFlushChecker.shouldDoManagedFlush( transactionCoordinator, status );
    }
    catch ( SystemException se ) {
        setRollbackOnly();
        throw exceptionMapper.mapStatusCheckFailure(
                "could not determine transaction status in beforeCompletion()", se );
    }

    try {
        if ( flush ) {
            LOG.trace( "Automatically flushing session" );
            transactionCoordinator.getTransactionContext().managedFlush();
        }
    }
    catch ( RuntimeException re ) {
        setRollbackOnly();
        throw exceptionMapper.mapManagedFlushFailure( "error during managed flush", re );
    }
    finally {
        transactionCoordinator.sendBeforeTransactionCompletionNotifications( null );
        transactionCoordinator.getTransactionContext().beforeTransactionCompletion( null );
    }
}
标签
java
hibernate
jpa
bean-validation
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!