Julien Martin wrote:
Mark Spritzler wrote:If you create individual transactions per loop, then you will be using more than one Connection, which isn't a great use of a scarce resource.
But if you have to, I recommend moving that code that is transactional into its own public method, and add the @Transactional annotation to it.
Mark
Hi Mark,
Why a public method? Can't I use a private method?
Good point about the number of connections. I was not aware of that problem. Is there not a way to avoid using more than one Connection (apart from using an annotation arount the whole method)?
Regards,
Julien.
You want an architecture that sets Transactions at the Use Case level for many reasons. 1) it just makes more sense.
2) With Spring, and Spring's resource management with a TransactionManager and a DataSource, Spring will get just one connection for your entire Use case and handle Exceptions for you and also make sure it is committed/rolledback, Connection put back to the connection pool, etc.
3) You want Transaction's ACID principle and if you look at your use cases you will see that you want them to completely succeed or fail, commit or rollback for its entirety. Without that, you might have partial commits. Meaning that loop loops for half the iterations, then fails and stops. The first half of your data was committed, but not the last half.
The reason for a public method is that Spring uses Dynamic Proxies to add transactionality to your code, which means a DynamicProxy of your interfaces of your class. If your method is not public and in the interface, then it will not be transactional.
I highly recommend getting Spring In Action third edition and start learning about the features of Spring and how it works. Otherwise, it is very easy to not have a clean architecture/design and therefore clean code.
Thanks
Mark Spritzler