Replies: 1 comment
-
I replaced the ExecutorService with @asynchronous from org.eclipse.microprofile.faulttolerance as it seems the more 'Quarkus' approach but functionally no different best I can tell. However I could not find any Quarkus approach to synchronize the transactions. So to hopefully solve the issue of needing to guarantee that the data is saved to DB before the custom lock ends I wrapped all that code in yet another @transactional(Transactional.TxType.REQUIRES_NEW) method internal to the lock/sync code. Is there a better way to do this? Does Quarkus have any framework support for syncing transactions? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What is the procedure in Quarkus to synchronize transactions?
I have a case were we get lots of REST requests where we have to respond with 202 and do the work in a new thread, where we currently use ExecutorService to create new thread. These threads will check if a record exists in the DB and if not will create it. The problem is we need all of these services/threads to be synchronized on a particular ID in the various messages as we don't want to create duplicate DB records with that message ID.
Our current approach uses @transactional(Transactional.TxType.REQUIRES_NEW) on the method that does the DB check/create and it also uses a Lock internally on the message ID to make sure those are synchronized. Inside the lock we call persist on the DB using Panache but that won't be saved to DB until the TX ends and that is after the lock is done. Although this approach seems to work it seems we have no guarantee that the data is always saved to the DB before the next task enters the lock.
I tried adding a getEntityManager().flush() inside the lock but get this incorrect error:
java.lang.IllegalStateException: The default datasource has not been properly configured. See https://quarkus.io/guides/datasource#jdbc-datasource for information on how to do that.
It is incorrect because the DB is configured and works fine except for the flush().
What is the Quarkus way to synchronize transactions where we must save to DB before next thread does work in the TX?
Beta Was this translation helpful? Give feedback.
All reactions