transactions - WCF service writes log only if client receives results -


i'm working on wcf service our new code interoperate legacy system. process goes this:

  1. client calls service request legacy system.
  2. service writes request database.
  3. legacy system services request db in own time , writes results db (updating status flag results ready).
  4. client retrieves results calling second service method, polls db until ready flag set.
  5. just before returning results, service updates status flag client has results, related db rows can deleted.

my concern race condition @ last step. can see happening:

  1. service updates status client has results.
  2. client times out after waiting service poll db.
  3. service tries return results. hilarity ensues.

one way solve have 3 service calls instead of two: second call retrieves results, , last 1 explicit acknowledgement client has them. i'd know whether there way doesn't impose "protocol" burden on client though.

i've looked briefly using transactions in wcf, , sounds might able need. client (optionally) starts transaction, flows service, uses if it's there, , commits when done. seems if implicitly "third call".

does idea have merit? disadvantages can see? there other avenues explore?

using transaction flow possible flowing transaction in polling scenario (in each poll call) terrible architecture. need transaction flow real read operation service modifies record , returns data client. client commit transaction , commit changes performed service.

using transactional processing places additional requirements on service , clients.

another approach can transactional msmq:

  1. client calls service request legacy system = client sends message service's queue
  2. service writes request database = service processes message queue
  3. legacy system services request db in own time , writes results db (updating status flag results ready).
  4. service polls database , places messages correct client queues. placing message , modifying database records runs in transaction
  5. client processes incoming message

transactional queue allows transactional reading (the message removed queue if transaction committed) , writing (the message added queue if transactions committed). allow deleting records before client reads message because message remain in queue until reads (or until timeouts , after can passed error queues).

in both cases should think clients consume service. transaction flowing can interoperable not every web service stack supports it. msmq not interoperable.


Comments

Popular posts from this blog

c# - SharpSVN - How to get the previous revision? -

c++ - Is it possible to compile a VST on linux? -

url - Querystring manipulation of email Address in PHP -