-
1. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
lafr Sep 7, 2018 12:25 PM (in response to sergiu_pienar)Does the solution given at WildFly 14 + Hibernate 5.3.6 - no transaction is in progress help you too?
Sounds to be a similar problem.
-
2. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 7, 2018 1:50 PM (in response to lafr)Indeed it sounds like a similar problem but unfortunately that solution does not apply here. I'm running into the exact same issue as described here: https://stackoverflow.com/questions/49536283/execute-query-with-native-query-update-query-in-hibernate-5-x but without the Spring component. I've tried the solutions described in the stackoverflow post (replacing openSession() with getCurrentSession() and adding @Transactional on the EJB method that does that call) but to no avail.
-
3. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
smarlow Sep 10, 2018 9:46 AM (in response to sergiu_pienar)One question to answer, is whether Hibernate ORM 5.1.14 was actually joining the Hibernate session, to the active JTA transaction. Knowing the answer to that, would be helpful in this discussion, as to exactly what action should be taken. As I would expect that its best for your application (with Hibernate 5.3, to keep working the way it was with 5.1).
With Hibernate ORM 5.1 in use, you could enable TRACE logging for both org.hibernate + com.arjuna (see troubleshooting doc). Also, change your call to sess.flush(), to:
System.out.println("before flush call");
sess.flush();
System.out.println("after flush call");
Then, in the WildFly console output (and server.log), you should verbose output that tells you when the Hibernate 5.1 session was actually flushed. As in whether it was flushed independent of the JTA transaction (e.g. output will show the the session being flushed before JTA transaction completes/commits) or if the session was flushed after the JTA transaction completes/commits (indicating that the Hibernate 5.1 session was auto joined to the JTA transaction).
It may just be that Hibernate wasn't auto-joining the session to the JTA transaction, which would be fine in 5.1 (session.flush() will work) but with 5.3, session.flush will not work anymore, unless you also set the following in the session factory configuration: "hibernate.allow_update_outside_transaction=true".
-
4. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 11, 2018 2:16 AM (in response to smarlow)Hi Scott,
Added the System.out.println's as you said:
08:59:12,234 INFO [stdout] (default task-1) Before flush call 08:59:12,234 INFO [stdout] (default task-1) After flush call 08:59:12,299 ERROR [org.jboss.as.ejb3.invocation] (default task-1) WFLYEJB0034: EJB Invocation failed on component CACUserDocumentRoleBean for method public abstract void com.acme.business.document.CACUserDocumentRoleLocal.update(java.lang.Long,java.lang.Long,java.util.List) throws com.acme.business.CACException,javax.ejb.EJBException: javax.ejb.EJBTransactionRolledbackException: Executing an update/delete query
I'm also attaching the hibernate.log (it has contents from both com.arjuna and org.hibernate).
I'm running hibernate with hibernate.allow_update_outside_transaction=true already, as I need it for I've ran across this issue WildFly 14 + Hibernate 5.3.6 - no transaction is in progress before.
Thanks !
-
hibernate.log.zip 64.1 KB
-
-
5. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
smarlow Sep 11, 2018 10:14 AM (in response to sergiu_pienar)Hi,
I expected to see the println output and log output, merged in your server.log, but at line 5683, I see the call to setRollbackOnly(), which indicates that is the important section for me to read, so will see what I can see just previous to that. After reading, I'm not confident that I am correctly reading the hibernate.log information, especially this part which doesn't seem to show any Hibernate calls:
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImpleManager.resume
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.arjuna] (default task-1) BasicAction::addChildThread () action 0:ffffc0a8006a:-5c7a1d24:5b9758dd:28f adding Thread[default task-1,5,main]
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.arjuna] (default task-1) BasicAction::addChildThread () action 0:ffffc0a8006a:-5c7a1d24:5b9758dd:28f adding Thread[default task-1,5,main] result = false
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.equals
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.setRollbackOnly
2018-09-11 08:59:12,302 TRACE [com.arjuna.ats.arjuna] (default task-1) BasicAction::preventCommit( BasicAction: 0:ffffc0a8006a:-5c7a1d24:5b9758dd:28f status: ActionStatus.ABORT_ONLY)
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.equals
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.equals
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.getStatus: javax.transaction.Status.STATUS_MARKED_ROLLBACK
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImpleManager.suspend
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.arjuna] (default task-1) BasicAction::removeChildThread () action 0:ffffc0a8006a:-5c7a1d24:5b9758dd:28f removing 8
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.arjuna] (default task-1) BasicAction::removeChildThread () action 0:ffffc0a8006a:-5c7a1d24:5b9758dd:28f removing 8 result = true
2018-09-11 08:59:12,304 TRACE [com.arjuna.ats.jta] (default task-1) TransactionImple.equals
I think it would help, you also print the query string that is passed in and see if your server.log also contains the log output and attach that instead of the Hibernate log. I think that might help me better understand the trace output.
Scott
-
6. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
smarlow Sep 13, 2018 9:32 AM (in response to smarlow)Hi,
In addition to providing the server.log contents, could you also enable TRACE logging for "org.wildfly.transaction.client", as that is involved in transaction manager operation now. If your server.log has too much information to share, please just include the lines that contain "org.wildfly.transaction.client", "com.arjuna", "org.hibernate" and your print output. Iniitial goal is to better understand why the Hibernate session is not joined to the JTA transaction and whether there is a bug with that. It would also be great if you could add an additional System.out.println("sess.isTransactionInProgress() = " + sess.isTransactionInProgress()), which I think will tell us if the Hibernate session is joined to the JTA transaction.
Thanks for reporting this and the other (result set is empty) issues, your help is appreciated!
Scott
-
7. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 13, 2018 10:06 AM (in response to smarlow)I'm attaching the server log that has the com.arjuna, org.hibernate, org.wildfly.transaction.client redirected to it.
Also, I don't seem to have a sess.isTransactionInProgress() on my org.hibernate.Session sess object. I don't find such method on the javadocs (Hibernate JavaDocs ) either.
The query I'm running is something like this:
DELETE FROM com.acme.dao.document.UserDocumentRole as dr WHERE dr.userId = :userId
-
server.rar 347.1 KB
-
-
8. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
smarlow Sep 13, 2018 10:04 AM (in response to sergiu_pienar)Yes, if possible, having the hibernate log in the server.log would be easier to read. I'd expect that simply not configuring the hibernate logging via separate (Hibernate) log configuration, but instead simply enabling category "org.hibernate" for TRACE, in your WildFly standalone.xml would accomplish that.
Regarding, sess.isTransactionInProgress(), could you instead try using sess.isJoinedToTransaction()
-
9. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 13, 2018 10:28 AM (in response to smarlow)Added the System.out.println with the sess.isJoinedToTransaction(). The outcome is:
17:10:12,338 INFO [stdout] (default task-1) Is joined trans? true
17:10:12,340 INFO [stdout] (default task-1) Is joined trans? true
17:10:12,346 INFO [stdout] (default task-1) Before flush call
17:10:12,346 INFO [stdout] (default task-1) After flush call
17:10:12,409 INFO [stdout] (default task-1) Is joined trans? true
for the below piece of code:
System.out.println("Is joined trans? " + sess.isJoinedToTransaction()); count = query.executeUpdate(); System.out.println("Is joined trans? " + sess.isJoinedToTransaction()); System.out.println("Before flush call"); sess.flush(); System.out.println("After flush call"); System.out.println("Is joined trans? " + sess.isJoinedToTransaction());
I have 2 deletes running one after the other. The first one executes nicely while the second one returns with false for the isJoinedTransaction() that is placed before the execute update.
I suspect that the first query is altering and commiting its values and the second one looks maybe at a stale copy ?
The triggering method is like so:
private void saveRolesAndNotifications(final User user, final Long spaceId, final List userRoles) throws CACException { Long userId = user.getId(); super.validateNull(userId); try { this.logRoleChanges(user, spaceId, userRoles); // save user system roles UserRoleLocal userRoleEjb = UserRoleFactory.getLocal(); // here is the first call to the delete methods -> the ones that say that the session is joined userRoleEjb.update(userId, spaceId, userRoles != null ? userRoles : new ArrayList()); // save user document roles List docRoles = user.getAssignedDocumentRoleIds() == null ? new ArrayList() : user.getAssignedDocumentRoleIds(); // the second call to the delete methods -- this time the session is not joined any longer and hence the exception UserDocumentRoleFactory.getLocal().update(spaceId, userId, docRoles); // save userNotifications UserNotificationFactory.getLocal().update(userId, spaceId); } catch (NamingException e) { UserBean.LOGGER.error("Lookup exception: ", e); throw new EJBException("Exception working with EJBs", e); } }
-
10. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 17, 2018 4:28 AM (in response to sergiu_pienar)I was missing this configuration property:
hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory
After putting this in place it all seems to be working now.
-
11. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
simkam Sep 17, 2018 4:42 AM (in response to sergiu_pienar)1 of 1 people found this helpfulNote that this property has been deprecated according to Hibernate ORM 5.3.6.Final User Guide. You you should use the hibernate.transaction.jta.platform instead. I think that correct value would be "
JBossAS".
-
12. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 17, 2018 7:27 AM (in response to simkam)Replacing cfg.setProperty("hibernate.transaction.factory_class", "org.hibernate.transaction.JTATransactionFactory") with cfg.setProperty("hibernate.transaction.jta.platform", "JBossAS") in the code that builds the session factory leads to the same problem as described when opening this thread.
-
13. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
smarlow Sep 18, 2018 2:53 PM (in response to sergiu_pienar)Sergiu,
Could you also try setting cfg.setProperty("wildfly.jpa.jtaplatform","false"). I'm curious if https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/ServiceContributorImpl.java#L40 is causing any of these problems when it sets https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5_3/src/main/java/org/jboss/as/jpa/hibernate5/service/WildFlyCustomJtaPlatform.java#L31 to be the default Hibernate ORM JTA platform for the application. If you have multiple session factories/persistence units in your application, I think the first session factory to be registered on your application classpath, will respect the "wildfly.jpa.jtaplatform" setting for all session factory/persistence units.
If you could try the above, that might give us a bit more information. I think that we need a tracking https://issues.jboss.org/browse/WFLY (JPA/Hibernate) jira for this problem that your experiencing as well. I'm not yet sure of how to describe this bug exactly (assuming it is a bug), which is why I'm asking you to do more testing (if possible).
By the way, Hibernate ORM 5.3, replaces "hibernate.transaction.factory_class=org.hibernate.transaction.JTATransactionFactory", with a determined JtaPlatform to use. I'm not exactly sure of which JtaPlatform is used.
Thanks,
Scott
-
14. Re: WildFly 14 + Hibernate 5.3.6 results in Caused by: javax.persistence.TransactionRequiredException: Executing an update/delete query
sergiu_pienar Sep 18, 2018 3:16 PM (in response to smarlow)Hi Scott,
Unfortunately the team I'm working in has decided to put a lid on the migration to WF14 since it proved to be too time consuming for us at this point. We have WF13 working and that is good enough for us now. We assumed migrating to WF14 would be a less problematic migration but since this is not the case we've called it a day.For the issues's reference we have multiple session factories in the app - the one that was working out of the box, even on WF14, was the one defined in hibernate.cfg.xml and which was bound to the classpath and JNDI in our case. For every other tenant of the app we would then create, at runtime, session factories which did not work until I added the configuration setting I mentioned in a previous reply (even though on WF13 all works w/o any changes to the codebase).
Once I fixed the above problem I ran into issues with creating the database - which is done from an ant script that runs on a serverless integration of Hibernate. I tried setting the transaction factories to JBossAS or JBossStandalone (not sure on the exact naming now) but to not much use.
Thanks for you help !