Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have developed a WCF service which acts as an API to our system.

some of the methods expose functionality which eventually writes and updates data to DB.

Lets say that the client sent one of those requests, the service performed the needed operations while the client disconnects for some reason and did not get the response.

the response holds information about success/failure of all sub-operations

An example of "problematic" data being updated - "Add X amount to Balance of Member M".

So if the client did not get the response - the client doesn't know that the data was updated.

How should we deal with this scenario while keeping the client side implementation as clean as possible?

share|improve this question

3 Answers 3

up vote 3 down vote accepted

Send a transaction Id.

The server stores the transaction ID (And the client ID).

When a new transaction is sent the server checks if it has already been processes.. If it has is sends an error code the the client.

share|improve this answer
    
We don't want to return an error, we want to return the actual response, in this case, we will have to save all the responses, which can fatten the DB, plus the chance of client side sending the same ID can be high... –  Mithir Nov 2 '11 at 14:14
1  
transaction IDs need to Unique... Who cares bout a Fat db? –  Morons Nov 2 '11 at 14:26
    
If you are dealing with important transactions EVERYTHING to be logged! Fat Db (smh) –  Morons Nov 2 '11 at 14:33
    
just to make things clear - We do have a transaction table - every transaction which passed gets a record with all the details. but what if for some reason the DB is down, and some or all of the operations failed - we still want to notify the client(in the context of the request) –  Mithir Nov 2 '11 at 14:50
    
if the Client does not get a response, the client must ask for a status... Then the server will respond with the current status ("DB is down, try again later"). The server cannot initiate a response to a request it may not know ever existed. -- for example : Client sends a request that gets lost or corrupted and never makes it to the server. The server can't EVER respond. So the client MUST make a new request. –  Morons Nov 2 '11 at 15:29

If it's vital that the client receive the response, then you'll have to do a two-phase-commit type of interaction (client invokes service; service returns token of some sort; client ACKs with token). It's not clear from your question though whether this is really required or simply "nice to have". Would it be acceptable to provide a history-type service, where the client can query for the status of the last (possibly the last N) service invocations?

share|improve this answer
    
it's really required. about the two-phase-commit - what would I do if the client does not ack? I will still have to save all those responses.. and then the question is - how many should I save... –  Mithir Nov 2 '11 at 14:22
    
You don't save any. What you have to do is enter a compensating transaction to undo the effects of the original. That way, the next time the client connects, it's as if they never executed the original request. You'll need to make log entries for everything, of course, but you shouldn't need to save any state for the client. –  TMN Nov 2 '11 at 14:29
    
maybe i exaggerate here... but what if the client sends an ack but the ack does not reach... now the client thinks everything is ok, but we undo the changes... We are familiar with two-phase commit, it's used here when the scenario is clearer –  Mithir Nov 3 '11 at 7:25
    
If you don't get the ACK, then the client doesn't get the ACK back. It's a complete handshake both times: client makes request, server responds with token. Client ACKs with token, service ACKs with token. That way, both the client and the service know that both sides are OK. –  TMN Nov 3 '11 at 18:31

If I was designing the service I would do all of the database updates in a transaction. If the client disconnects prior to the completion of the process roll back the transaction. In this method if the client did not get a response the client can assume that the update failed.

If this is not acceptable you could create a set of tables for the submission process. Then compare each submission to all previous submissions (or at least those inside a certain window) that were disconnected. Then check and see if the submission is the same as the previous submission and return the results from the original... though I see so many potential pitfalls here.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.