General advice about transactions in Spring

Hello,

I have the following method (notice the comments //todo: transaction starts here, etc.):

public int traiterMailing(/*List<Sculpture> sculpturesChoisiesPourMailing*/) {//todo: gerer le cas où zero sculptures et gerer le cas où une adresse email est invalide.
        log.debug("traiterMailing");
        List<Sculpture> sculpturesChoisiesPourMailing = dao.findMailingNonTraitees();//todo: temp?
        List<Abonne> totaliteAbonnes = dao.findAllAbonnes();
        int compteursMailsEnvoyes = 0;
        if (sculpturesChoisiesPourMailing.isEmpty()) {
            return compteursMailsEnvoyes;//todo: threadsafe!!
        } else {
            for (Abonne abonne : totaliteAbonnes) {
                //todo: transaction starts here
                for (Sculpture sculpture : sculpturesChoisiesPourMailing) {
                    MailingAbonnePK mapk = new MailingAbonnePK(sculpture.getSculptureID(), abonne.getAbonneID());
                    MailingAbonne ma = new MailingAbonne(mapk, new Date());
                    dao.persistMailingAbonnee(ma);
                }
                this.mailAbonne(sculpturesChoisiesPourMailing, abonne);
                compteursMailsEnvoyes++;
                //todo: transaction ends here
            }
            List<Integer> sculpturesChoisiesPourMailingIDs = new ArrayList<Integer>();
            for (Sculpture sculpture : sculpturesChoisiesPourMailing) {
                sculpturesChoisiesPourMailingIDs.add(sculpture.getSculptureID());
            }
            dao.updateSculptureChoisiesPourMailing(sculpturesChoisiesPourMailingIDs);
            return compteursMailsEnvoyes;
        }
    }

I wish to use the equivalent of tx.begin() and tx.commit() respectively at //transaction starts here and //transaction ends here.

Can anyone advise which Spring class to use or whether I should refactor my method and if so how?

Thanks in advance,

J.

It looks like the entire method is a use case and would expect you want transaction started there and coomit/rollback based on success or failure of the entire use case.

Then you can define a bean for a TransactionManager and add <tx:annotation-driven> then you just add an @Transactional annotation on the top of your method.

Mark

Mark Spritzler wrote:It looks like the entire method is a use case and would expect you want transaction started there and coomit/rollback based on success or failure of the entire use case.

Then you can define a bean for a TransactionManager and add <tx:annotation-driven> then you just add an @Transactional annotation on the top of your method.

Mark

Hello Mark,

Not exactly. The intended behaviour is for the code portion between "//todo: transaction starts here " and "//todo: transaction ends here " to be a transaction. Additionally I wish that if one iteration of the following loop fails , nothing in between the code portion is persisted (i.e. it is rolled back) but most importantly, I would like for the loop to resume at the next iteration...

It that possible?

Regards,
J.

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

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.

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

Thanks Mark for this detailed reply. I am going to order the book you advised as soon as it is available.
Regards,
Julien.

Julien Martin wrote:Thanks Mark for this detailed reply. I am going to order the book you advised as soon as it is available.
Regards,
Julien.

You can sign up the MEAP program and get the pdf now. It is basically all finished.

Do you have a good reader like a Kindle or iPad or other tablet?

Mark

Thanks Mark. I would like to mark this as resolved but I can't find the button...

Julien Martin wrote:Thanks Mark. I would like to mark this as resolved but I can't find the button...

Marked