Announcement Announcement Module
No announcement yet.
transactions / sending mails Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • transactions / sending mails

    in one of my applications I want to rollback a transaction if sending a mail fails.

    But I don't like the fact that the communication with the mail server happens during

    the transaction as this operation could take some time, in which a database connection

    is allocated (bound to the transaction). If the server gets busy or the mail server is

    responding slowly, this could consume too many database connections.

    One solution could be to establish a JMS queue
    -> a JMS message is sent inside the transaction to indicate the need for a mail. If

    the message is sent successfully, the application can be sure that the mail will be

    sent and commit the transaction

    -> the message consumer does the communication with the mail server

    This would ensure that the mails are really sent but without synchronous behaviour

    (and the problems related to this).

    But this would require JTA transactions and also generally seems like a overkill of

    the problem. Isn't there a simpler solution (without the need for JMS and JTA)?

    Another way could be use JDBC instead of JMS and store the mail-data in a database

    table. This table could be checked periodically for new entries. But this must be done

    by a cluster-wide singleton component to prevent (theoretical) problems like duplicate

    mails and therefore doesn't look like a good and easy solution.

    Any comments or suggestions?

    Actually this is not a problem specific to Spring, but nevertheless I hope that this

    forum is the right place to discuss such issues.


  • #2
    If you insert a message in a JMS queue and have it handled by a MessageBean then you can't propagate the transactional context. The whole transaction must take place within the onMessage method in the MDB. This way you would know whether the sending of the email was succesfull before you commit the transaction. On the other hand, the commit could fail and now you have the email already sent and the transaction is rolled back - what is worse?


    • #3
      I don't need to propagate the transactional context. If the MessageBean fails to send the mail it simply indicates that it hasn't successfully consumed the message - the whole procedure will repeat. So at the time of the initial transaction the application can be sure that the email will be sent at some point of time. By the way, I'm not thinking of for instance illegal or wrong email addresses, but of situations like the mail server is not available.

      And I definately don't want to send the email before I know that the whole transaction succeeded. This would also be ensured by the JMS approach (he JMS-send operation will be rolled back in case of an error (JTA transaction))