Arun Singh Raaj wrote:As you said Transaction Manager takes care of ACID, does it mean that even if the application was stateful, the transaction wouldn't corrupt?
The answer depends on what you mean by a corrupt transaction. The transaction manager makes sure that all data you send to and retrieve from the database will be consistent between many requests. It can't guarantee that the data you sent to it in the first place was the data that you intended to send. This data can easily get corrupted before it ever reaches the transaction manager if your application is stateful and not synchronized properly.
Yes, you can write a stateful web application that handles requests correctly and doesn't corrupt data in the face of concurrent requests, but as soon as you start getting many concurrent requests it will grind to a halt as most of the requests are stuck waiting to enter some synchronized block and eventually time out.
you have to send confirmation email to the customer and generate an invoice. These two tasks have separate classes and methods. So do they need synchronization?
I'll elaborate on what Paul said. After the ticket booking transaction has committed, the web application can spawn separate tasks to generate the invoice and send a confirmation e-mail, and then directly return a response to the client. Even though these tasks may run in separate threads and use mutable objects, you don't have to synchronize between them because the tasks can be performed in isolation without requiring any shared data. Just remember to pass all relevant data to the tasks when you create them. If they have to access the database again that's a BIG NO NO.