Spring @Transactional and long-running business logic

[Sergei Prosvirnin]

I am having some problems with Spring @Transactional and hope to find a solution here. I have a method in the service labeled as @Transactional which works by calling a method to request data via HTTP protocol (I'm using Apache HttpClient now), parsing the response and writing the result to the database. Since it all works in one method I'm afraid that this may cause transaction cancellation, because my project has a transaction time limit and request from external API may be really long.

Here I would like an answer on how to most correctly separate HTTP request+response parsing and database operations in such a case. As an option it is possible to have two methods one for transaction and the other for the rest of the logic, but I already have an assumption that there is a generally accepted design pattern for such tasks.

[Tim Holloway]

Well, for my JPA webapps, I have 3 layers: one for the raw database Entities, one for CRUD/finder operations on those entities (and in some cases, parent/child aggregates), and the highest layer is for business database service logic: graphs of entity relationships organised into working sets so that they can be detached and re-attached. The two logic layers: serice and DAO , I have marked as transactional, with the transaction context being inherited. That is to say, DAO operations made on behalf of a service function operate in the transaction of the service function.

A long-running and possibly failing operation such as HTTP is something that I would try very hard to deal with before invoking the service layer. That is. in the Business layer or perhaps a special layer between Business and Database Services. I would try to avoid making in transactional. If it has to be transactional, then you are entered the realm of XA transactions and that's a whole different can of worms and required a lot more transaction support than the basic JPA transaction system provides.

[Sergei Prosvirnin]

Tim Holloway wrote:Well, for my JPA webapps, I have 3 layers: one for the raw database Entities, one for CRUD/finder operations on those entities (and in some cases, parent/child aggregates), and the highest layer is for business database service logic: graphs of entity relationships organised into working sets so that they can be detached and re-attached. The two logic layers: serice and DAO , I have marked as transactional, with the transaction context being inherited. That is to say, DAO operations made on behalf of a service function operate in the transaction of the service function.

A long-running and possibly failing operation such as HTTP is something that I would try very hard to deal with before invoking the service layer. That is. in the Business layer or perhaps a special layer between Business and Database Services. I would try to avoid making in transactional. If it has to be transactional, then you are entered the realm of XA transactions and that's a whole different can of worms and required a lot more transaction support than the basic JPA transaction system provides.

Thanks for the advice!