Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
Win a copy of Event Streams in Action this week in the Java in General forum!
  • 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
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

How to save multiple @Entity objects of the same type in a single transaction using @Transaction

 
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hello All,

Can multiple @Entity objects (of the same type) be persisted within a single transaction?

Can this be done in a class that has the @Transaction annotation?

Many thanks.

-Ravi
 
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it can, and it's a fundamental characteristic of some of my more complex web applications.

In fact, I have 2 separate layers with @Transactional classes in them: the business persistence layer (services) and the primitive persistence layer (DAOs).

My DAO layer is mostly one DAO class per @Entity (database table) with occasional exections for the tighter parent-child relations. The DAOs are almost exclusively basic CRUD functions.

My Service layer contains the business logic where different types of Entities interact. Typically there's a "working set" tree of related Entities that I deal with here. My higher-level business and GUI functions deal with detached working sets. In the Service layer, they become attached and persisted. The @Transactional nature of the Service layer functions ensures that the entire working set is handled as an atomic unit. The DAOs are also @Transactional, but for consistency's sake, they are rarely called directly by anything higher than the service level (keeps me from having to hunt through multiple layers). Since I'm using accumulative transactions, all the DAO transactions are performed as part of their service-level transactions.

I also use the @Repository annotation on both DAO and service classes, as that facilitates auto-wiring them.
 
Ravi Danum
Ranch Hand
Posts: 165
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim,

Thank you very much for your input.

I also have a layer with one extended CRUDRepository interface per @Entity object.  That is when I noticed that each insertion was done in a single transaction.

Would it be possible to add one extra method to each of the CRUDRepository interfaces to handle a configurable number of records to be persisted within one transaction?

-Ravi
 
Tim Holloway
Bartender
Posts: 20924
127
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the scheme I'm using, usually there's an "anchor" record for the working set that's going to be persisted. But there's no reason why I couldn't just as easily pass in a List, Map, Array or other collection of records,
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!