Upgrading to 1.13.1.Final causes java.sql.SQLException: Deferred enlistment not supported

[David Hoffer]

After upgrading to 1.13.1.Final we often get the following error.

2021-04-14 09:36:50,537 WARN  (pool-14-thread-1) [org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logExceptions()] SQL Error: 0, SQLState: null

2021-04-14 09:36:50,537 ERROR (pool-14-thread-1) [org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logExceptions()] Deferred enlistment not supported

This happens when we make the following call on an EntityManager instance.

em.createNativeQuery(RLS_QUERY).setParameter("user", SYSTEM_USER).setFlushMode(FlushModeType.COMMIT).getSingleResult();

This part isn't logged but the exception is:

java.util.concurrent.ExecutionException: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not prepare statement

cause: java.sql.SQLException: Deferred enlistment not supported

What does this mean?

This did not occur using 1.12.2.Final

Is this a bug in 1.13.1.Final ?

Are we doing something wrong in our code?

-Dave

[Guillaume Smet]

Could you open an issue on GitHub with a reproducer?

We need to have a closer look.

Thanks!

[Luis Barreiro]

Hi Dave,

'Defered enlistment not supported' means that the JDBC Connection was acquired without a transaction and, later on, was being used in the context of a running transaction.

This behavior is not something new, so a reproducer will definitely be helpful.

Regards,

Luis Barreiro

Middleware Performance Team

--
You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e47758d1-b319-44bd-a3bc-a5efa12a06b6n%40googlegroups.com.

[David Hoffer]

Thanks for the explanation.

We believe we have fixed this on our end.  We had some bad usages of EntityManager...we refactored our code to be more consistent how we inject things.  

In summary what we have found is that if we have Singleton or ApplicationScope, and we generally do, then we always need to inject an EntityManagerFactory into those instances and call createEntityManager() when we actually need to have and use an EntityManager (e.g. REST method/etc).  That works fine and is more clear to read/understand too; as I guess CDI can mix scopes (RequestScope inside ApplicationScope) but its very confusing and has not worked well so we just avoid that and things seem to work fine.

-Dave

[Stuart Douglas]

So the EntityManager is transaction scoped, and if there is no TX it is request scoped.

Basically if you inject the EM and a TX is active it will be tied to that TX and closed when the TX completes. If there is no TX a request scoped one is created and closed when the request completes.

I don't really see how you could get that exception with an injected EM? If you do operations before a TX starts, then start a TX the EM should be a different EM within the TX.

Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/e0bda405-2e7f-4bfe-a9c5-a36af4750737n%40googlegroups.com.

[David Hoffer]

Regarding the prior injected EM...yes we did inject that but it was used in a Google LoadingCache...so used to init the cache but then also used hours later in the loader when it loads new data...that was causing this error.  If we inject an EMF and then call createEntityManager() when we need the EM it works perfectly.

-Dave

[Sanne Grinovero]

On Thu, 15 Apr 2021 at 00:58, David Hoffer <dhof...@gmail.com> wrote:

Regarding the prior injected EM...yes we did inject that but it was used in a Google LoadingCache...so used to init the cache but then also used hours later in the loader when it loads new data...that was causing this error.  If we inject an EMF and then call createEntityManager() when we need the EM it works perfectly.

+1 that sounds like a more reasonable approach.

I believe this wasn't throwing an exception in previous versions because Hibernate ORM would acquire a connection before each statement, and release the connection again to the pool immediately after each statement.

This used to be necessary for other reasons which have been resolved, and we use now a more efficient approach which binds the same connection instance to the lifecycle of the Session (DELAYED_ACQUISITION_AND_RELEASE_BEFORE_TRANSACTION_COMPLETION)

Sanne

[David Hoffer]

@Sanne Thanks for the explanation of why this error is now thrown.  Can you elaborate on the lifecycle a bit more?  What is a Session in this context?

When we get a new EntityManager we have to call set_config(setting_name, new_value, is_local) because we use that to do row level security (RLS) checks in the DB and here too the is_local parameter is defined this way:

set_config sets the parameter setting_name to new_value. If is_local is true, the new value will only apply to the current transaction. If you want the new value to apply for the current session, use false instead.

Here too we are not clear what is the meaning of 'session'.

Can you clarify what is meant by 'lifecycle of the Session '?

Thanks,

-Dave

[Paul Pedro]

I upgraded as well from 1.12.2.Final to 1.13.4.Final and had the same issue.

I still dont really understand why it worked with 1.12 but removing transactional from subfunction was the solution for me:

@Transactional( Transactional.TxType.NOT_SUPPORTED )

function A(){

Do something here...

Run function B();

}

@Transactional( Transactional.TxType.REQUIRES_NEW )

function B(){

 //And here happened the ERROR

}

I removed the Transacional REQUIRES_NEW from function B and everything is working in 1.13.4.Final as well. :-/

Hopefully I could help someone

[Stuart Douglas]

Is this using an injected EntityManager or a programmatically created one?

Stuart

--

You received this message because you are subscribed to the Google Groups "Quarkus Development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to quarkus-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/f1f2496b-ae05-46c7-90ab-e1864950eda8n%40googlegroups.com.

[Paul Pedro]

Injected EntityManager

[Stuart Douglas]

Do you have a reproducer? That sounds like something we should look into.

Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/quarkus-dev/25745bda-9bbd-4bb5-adf3-305c5c9d2fcen%40googlegroups.com.

[Paul Pedro]

Not really a producer, but maybe this helps as well:

https://github.com/quarkusio/quarkus/issues/17311

In the code there is only one line that has changed between version 12 and version 13.

I am sorry, I thought about how to recreate it, but that would have been too cumbersome

I dont know what has changed with the entityManager from version 12 to 13, but anything isnt working correctly with Transactions / scopes anymore. In our second project we got this error as well.

Changed now back to version 12.

Regards Paul

.