1

I might be getting myself confused here but say I want a service to be idempotent. That is, receiving the same request more than once will not change the state of the system. This makes sense to me when receiving messages in a disconnected integration system. For example, receiving messages over MSMQ and having some form of service dealing with the messages being received. You want the service to be in a consistent state even if it receives 10 duplicate messages.

What I am now struggling to get my head around is what about with a standard WCF SOAP service that performs CRUD operations. Does the idempotency question only come into affect if it is an asynchronous call? Is a syncrhonous call by nature idempotent? Looking at CRUD operations, the only one which is not idempotent is create. Can you have duplicate create calls to WCF?

Thanks

Jon Archway
  • 4,852
  • 3
  • 33
  • 43

2 Answers2

0

I guess it would depend on what you define (in your domain) as duplicate. Once that is defined you can then run checks before creating your record. e.g. I have a Person with FirstName, LastName, etc... a duplicate person would be identified by FirstName + LastName.

What kind of duplicate messages would you expect your service to receive? The same client 'clicking the submit button twice'? or two different clients trying to update a record at the same time?

Jay
  • 6,224
  • 4
  • 20
  • 23
  • So do you have checks on all your create operations to make sure a duplicate is not added or at least an exception is returned to the user to inform them that the record already exists? – Jon Archway Jul 21 '11 at 14:38
  • How you enforce duplicate detection is up to you. You can create unique constraints on the DB side, have your app perform selects inside of a transaction, or both. Throwing an exception is acceptable here, or you can return something like 'operation status = failed'. – Jay Jul 21 '11 at 16:20
0

Synchronous or asynchronous does not matter. Think about what if the request is process but before receiving the response the connection is lost. So your client receives an error but the server has processed the request. Update is idempotent because in worst case you update the record twice.

Yann Olaf
  • 597
  • 3
  • 12
  • OK, but what about that operation when they are performing a create. Create has occurred in the database, error during response, user gets error. User then tries to add again, if using something like an identity column then the record will be added again. I guess you would then need to implement some checking to make sure this scenarios does not occur? – Jon Archway Jul 21 '11 at 14:37
  • The simplest way is that the identity is generated by the client (e.g. with a GUID). You can also create the object on the server first than let the user edit the new entry. But then you have to delete the object if the user cancels the creation. – Yann Olaf Jul 21 '11 at 14:45
  • Surrogate identities don't always work if you have more than one client connected. However, 'firstname + lastname' wont always work either. It just depends on what you are willing to accept. – Jay Jul 21 '11 at 16:22