Transaction handling in web apps

Question

I have noticed in most Web applications that whenever there is a transaction involved in a train of pages, the transaction handling happens in the database layer. In a web application where there could be numerous users running such transactions, handling all the transactions could be a critical thing. I agree that the database layer is quite efficient in doing this and provides quite a number of features to do this efficiently.

My question is if a web application is built over a database which does not provide support transaction handling, is there a way to handle these transactions in the other layers ?

Answer 1

A database that does not handle transactions? Better get a new database.

I disagree - transactions are not handled in the persistence layer. I think they properly belong in the service layer, because service methods are what map to units of work and use cases. A single service call might involve more than one database and model object, so all of them need to be a single, ACID unit of work. That's not possible if the persistence layer handles transactions.

A design like this can handle transactions even if the database doesn't support them. The service can implement compensating calls in the event of a rollback. Not possible if you jam that logic into the persistence tier.

In my opinion, you have to have a separate service interface between the web and persistence tiers. The web tier only handles HTTP requests, routing to services, and formulating responses to send back. The services do the work.

The services CAN be web services, if you choose to deploy them that way, but there are lots of deployment choices. The separate service tier is independent of those choices.