Spring transactional layer setup

Squadless
Squadless used Ask the Experts™
on
Hi, I'm designing the backend of an app where i've a few scenarios and i'd like to get the base right in terms of how to properly design my daos and daoimpls and service layers.  Whats important is that i have situations where if a request comes in to add an entity, lets say, multiple tables will be populated, so for example entity table and generic details table.  I would like to create an ecosystem where my transactions are properly defined and are correct meaning that
if(add){
 -row inserted into table1
 -20 rows inserted into table2
 -21st row fails to be inserted into table2 due to a .. lets say primary key violation..
 - ROLLBACK ENTIRE transaction.
}
My current design is
Entity - pojo
EntityDao - interface that has methods like boolean addEntity(Entity entity);
EntityDaoImpl - extends EntityDao, the actual implementation where the addEntity method does a insert into the database.

Ive ran and tested and all is fine except transactional aspect is not working.  
My QUESTION is.. do i need a service layer somewhere in between if i want to handle transactions or marking the methods inside my dao impl class @Transactional(propagation = Propagation.REQUIRED, rollbackFor = Exception.class) is enough?

If i implement EntityServiceImpl where i have a method like addEntity that calls entityDaoImpl.addEntity() and wrap the EntityServiceImpl method @Transactional, is that better then having just a DaoImpl be transactional? i guess it is right so that i can commit or rollback and etc..

Thoughts?
THx
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
IT Business Systems Analyst / Software Developer
Top Expert 2015
Commented:
It would depend on exactly how you do you DAO code. Typically, the way I would do it (based on the somewhat limited view of what you are doing) is that each DAO method would handle ONE of the tables that you are dealing with, so in your above example, I would have two methods one for inserting into "table 1" that gets called once, and one of inserting into "table 2" that gets called multiple times. These calls would all be made from the service layer.

And if this is your case, you can't have the transactional setup at the DAO layer, because if your table 1 inserting method is marked transactional, then as soon as that method returns, the data is committed. In this case, you put your transactional setup on your service layer so that the group of DAO method calls all occur within ONE service layer method and this method marks the boundaries of the transaction, ie. if anything fails within that method, ALL calls made within are rolled back.


Now, there may be some arguments along the lines that having a service layer might be overkill for simpler applications, and you would just have a DAO layer where ONE method does the inserts into both table 1 & 2. You would have to evaluate exactly what you are doing and design it accordingly.

One thing you would definitely want to avoid is having the transactional setup in multiple layers, ie. for some operations the transaction is on the service layer, and for others its on the DAO layer. So in saying that, if you think that you may at some point require a service layer (so that you can co-ordinate multiple DAO layer calls), it's probably best to just go with that from the start, even if it does end up that the majority of service layer methods ARE one liners that just call on to the DAO layer.

Hope that helps, if anything is unclear, let us know.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial