Hi.

I have a Session Bean method that as part of its process is sending an email using the javamail api.

However, as the method is part of a CMP transaction, to ensure that the email is valid, I would like it to be sent only when the transaction is committed. Thus, if the transaction gets rolled back the email will not be sent.

I have no idea how I might do this and would appreciate any ideas on what the best approach to achieve this might be.

I appreciate your help.

Regards,

John Miller

I believe the safest way to do this would be to use a store and forward mechanism. Keep identifiers, mailId's of all committed transactions in a table. Send mails later.

If there is another way, please shoot !

That is certainly the most obvious way of handling this scenario.

However, the problem with splitting it up in that fashion is that if the sending of the email fails, I have no way of rolling back the transaction that originally generated it.

Hi,
The java mail Api does not offer transactions. However you can do you stuff and put a message in a transactional queue ina transaction. The consumer of messages from tha quee will be aMDB that sends mails.
Best regards, Mircea

I think I prefer that solution.

However, my experience of JMS and MDB's isn't great, but I think your suggestion has essentially the same problem as the previous one. If the MDB encounters a problem sending the email, due to the asynchronous nature of JMS this will not be picked up by the client sending the JMS message. Consequently, the calling transaction will not be rolled back. Or am I missing something?

My problem is essentially that I only want to send the email if the transaction is going to be committed, but if sending the email throws an exception I want the transaction to be rolled back.

Sounds like you need to write an XA compliant wrapper around the javamail api ;-)

You dont happen to know of one already written do you?

<quote >but if sending the email throws an exception I want the transaction to be rolled back.</quote >

Your logic wont work and here is why : So even when your java mail api call returns ok, there is no guarantee that the mail has been successfully delivered. When the java mail api call retuns -- it it means is that the server has pooled your outbound email.

The mail server may not respond with the true status of the outbound email until it has exhauset all possiblities. This may may upto esveral hours or days before your mail server gives up trying to send the email.

When the java mail api call retuns -- it it means is that the server has pooled your outbound email.The mail server may not respond with the true status of the outbound email until it has exhauset all possiblities.

I understand what you are suggesting, but this is an acceptable scenario. The fact that there are many exceptional circumstances underwhich the initial connection and sending of the email can fail, is why the transaction should be rolled back.

I think the way around it would be to not just send an email, but to request a read receipt. Then have a listener listening to these acks, and commit the transaction after it is received.This would work for receiving email servers that are down and for bad email ids, altho the time to wait could be days. :)

However, this sounds like and is a complicated solution.

This might not be a feasible solution for most, and i think would be insecure and comes with its own set of problems anyways.

For most people, i think knowing that the mail has been relayed ahead would be enough.

This is a complicated situation, indeed. I this you should probably let your clients know that they're going to receive that email after the transaction has been completed. There is also a software, called J1939, and you could search for the full package, that handles reception and transmission of standard single frame and multi-frame messages.

Hi.

I have a Session Bean method that as part of its process is sending an email using the javamail api.

However, as the method is part of a CMP transaction, to ensure that the email is valid, I would like it to be sent only when the transaction is committed. Thus, if the transaction gets rolled back the email will not be sent.

I have no idea how I might do this and would appreciate any ideas on what the best approach to achieve this might be.

I appreciate your help.

Regards,

John Miller

 

 

The best way to do this is to write the bean logic and logic to send an email in  XA transaction in session bean. Any J2EE components can be added to XA-Transaction.