JDBC - Generic way of dealing with different objects in single transaction?
So I have Object A and B that I want to commit to the database in a single transaction. It seems easy as it is just a matter of setAutoCommit(false). However, since they are different objects, they come from different classes of the database layer (and hence, different methods).
I could try:
- Creating a new method that instantiate the database classes and pass around a connection parameter (inspired by this answer to the question "How to manage 2 DAO methods in a single transaction?"). While I love its generic approach, but if dataLayerForObjectA.class handles queries pertaining to Object A while dataLayerForObjectB.class handles Object B, where would this method that handles both belong to then?
- Adopting Unit of Work pattern, which I'm not even sure if I should be looking at this in the first place, because every examples I can find are all .NET framework. I tried to follow, but realized it ultimately leads to the same issue as above when the data reaches the database layer. All examples I find are just dealing with transactions of the same Object.
- Violating design principles by chunking everything in either 1 of the classes, or creating new classes for different combinations of objects. I don't want to resort to these.
It's likely I've overlooked certain things as most concepts are new to me, but in short, this is the same trouble I'm facing for the various approaches I looked at - the code doesn't belong to existing classes when keeping in mind of the Single Responsibility Principle, and that creating new classes for different kinds of combinations seems wrong.
UPDATE: Things seem to fine (for now) following Aseem Bansal's answer. Will update again if I encounter any issue in the future with his approach. Meanwhile I am open to any other kinds of answers.
Suppose that you have SalesPerson, Customer as your A and B. Now if you want to add a SalesPerson to the system you can use something like salesPersonService and if you want to add a new customer then you can use something like customerService. From your question you are clear till this point.
Now if you want to add an Order to the system, you will need to add two database objects.
I am assuming that you have a separate mapping table which maps the three tables. There can be one table but let's go with a separate table for our example.
Now ask yourself if you want to do this what is the logical xxxService for adding orders to the system? ordersService. If that requires something like
create connection create order and order mapping do stuff commit/rollback
Then that is the logical thing to do and so the answer is 3 but that does not violate design principles. It is the logical solution to the problem statement and thus not an issue.