3

I am investigating writing web services for an application. Within this application we do everything within transactions as "units of work" are often not single entities but multiple entities spanning multiple tables. There are situations where we want "All or nothing" and a transaction makes perfect sense. I am not really sure how to do this in a web-service however, nor if I even should.

I feel like web services should be stateless and the provided API should be built on a per-entity basis, yet I am unsure how to handle the "units of work" that should one part fail, a rollback should occur.

Should Web services be transactional? How would you implement transactions, would it be something along the lines of sending a "BEGIN TRANSACTION" and ending with an "END TRANSACTION"?

If web-services are stateless how do you deal with "units of work" that are not independent? Is there any definitive literature around that I can read on the topic?

thanks,

kgrad
  • 4,672
  • 7
  • 36
  • 57
  • I would think that the web service layer would not be an actor in the transaction, but rather request the transaction to be done by the layers below and report the result to the client, whether committed or rolled back. If you are being asked for a transaction logic that transcends what can happen within one application node, I would call that a "design smell". – wberry Jul 12 '11 at 17:11

2 Answers2

5

One of the canonical papers on the subject is Pat Helland's Life Beyond Distributed Transactions: an Apostate's Opinion. Highly recommended.

fumanchu
  • 14,419
  • 6
  • 31
  • 36
4

The web service might be all or none behind the scenes, but you have a choice as to what you expose to the client.

If you want the client to know about commit/rollback behavior, you have to provide "compensating transactions" as part of your API. So if one use case creates a new transaction, you have to provide a complementary method to delete it and tell the user if the create succeeded or failed. Same with all other methods.

I think this exposes too much of what the service is doing. Clients are forced to know too much. It's a poor encapsulation.

I think it's a better design to leave that knowledge hidden inside the service. Report back to the user about success or failure, but that's it.

This means you have to design your service to be coarse-grained enough to encompass a complete unit of work. Let it orchestrate data sources and other services to fulfill the use case.

duffymo
  • 305,152
  • 44
  • 369
  • 561