• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Rob Spoor
  • Henry Wong
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Carey Brown
  • Stephan van Hulst
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Frits Walraven
  • Himai Minh
  • Jj Roberts

Spring @Transactional and long-running business logic

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Saloon Keeper
Posts: 23409
159
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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!
 
If you like strawberry rhubarb pie, try blueberry rhubarb (bluebarb) pie. And try this tiny ad:
SKIP - a book about connecting industrious people with elderly land owners
https://coderanch.com/t/skip-book
reply
    Bookmark Topic Watch Topic
  • New Topic