I think this is what caused the database to get into this inconsistent state. Connections drop and in some cases rollbacks are interrupted by an exception. What I noticed, is that my postgresql server is hitting 100% IO usage.
#SPRING TRANSACTION MANAGEMENT EXAMPLE UPDATE#
I have an update after experimenting over the weekend. That would however not explain the inconsistencies I witnessed sometimes.ĭo you have any clues where to look further? What may be messing things up is that I am throwing a BpmnError in response to a RequestNotPermitted exception from a RateLimiter. Still I have this behaviour of inconsistency sometimes. In my REST controller or other alternative starting points, I should of course place a attribute. Therefore I would expect that all other calls are part of that same transaction and therefore no additional annotations would be necessary for calls initiated by the JavaDelegate. Setting the propagation level to NEVER gives an error. I have also see that the delegate is executed in a transaction. So the autoconfigured JpaTransactionManager by spring boot works better. I have been looking into this further and following the hints in the referred documents does not help me further, since I am using JPA to manage my application state.
#SPRING TRANSACTION MANAGEMENT EXAMPLE HOW TO#
However, it requires some additional configuration and I would like to know how to set this up. It seems to keep things simple and consistent. I want to use one datasource and one transaction to control the persistence operations from camunda as well as from my own application. I found some posts on using two distinct datasources, so that is a different setup. Hope you can share the best practices for this. Moreover, should I decorate all my JavaDelegate.execute methodes with as well as the REST endpoints that are provided and use the runtimeService to interact with the process model, or is this not necessary? I suppose the resolution is in setting up a shared platform transaction manager, but I am not sure.Ĭan you share the best practices for setting up correct transactional behaviour over a single datasource for both camunda updates and my application’s state updates? So it seems they use different transactions for their updates. The camunda process progresses faster than my application logic, leading to inconsistent states because mandatory data is not available in the application state. What I notice is that when the database is under some load, the models are not in sync anymore. Keeping the application state and its process state consistent.
I am setting up a spring boot application with an embedded Camunda process engine and want to store my application state in the same database as the camunda tables are, such that I can leverage an atomic transaction over the updates to the camunda tables and my application state.
0 kommentar(er)
