I am working on a REST µService application that has both high processing and high communication running on not very high-end hardware.
Usually, calls can be handled in a matter of seconds. I am going to take as an example the creation of an entity. Creating an entity requires to have information from external services and sometimes a parent local entity. This can lead to the following flow:
- Receive creation request
- Query local DB to fetch information on the parent entity
- Fetch external information to another service
- Internally process the information to create the new entity
- Persist the new entity
This usually takes around 2 seconds, however due to cold caches in other services, a high load on the server, etc., I have seen calls taking several minutes.
This ends up in a connection timeout in point 4 or 5, usually on a simple SELECT query. I guess (not sure) this may be because I am in the same transaction as in 2, which was closed and the SELECT query is not at fault, the transaction was simply closed before. The transaction timeout cannot be increased to multi-minutes values.
I am using Hibernate. I guess the same transaction is used for the whole call, however since there is only one .save() call, I don't think we actually need that behavior.
I am aware of the @Transactional annotation, but not deeply knowledgeable on how to properly design services with it. Should I request a new transaction on each call? Is there a guide on proper design for my use-case somewhere?
I actually do not need a transaction until the .save(), since previous calls are read-only.