Transactions across services?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Richard - 04 Apr 2006 00:47 GMT

Here's the scenario. An item is placed on a queue; this is the end of the
first transaction. A second transaction begins, a queue processor receives
the item from the queue, and decides which service (application server) to
send the data to for processing. After successfully processing the data,
the service sends proper return codes (some type of notification) to the
queue processor, and the queue processor removes the item from the queue and
commits (assuming successful processing). Under that framework it doesn't
seem easy to maintain transaction state. In other words, after the data is
sent for processing, a lost connection, for example, would prevent knowing
whether or not the data was successfully processed. It seems that the round
trip can only be easily guaranteed when the framework is Service Broker to
Service Broker. Is that correct?

Thanks,
Richard

Reply to this Message

Remus Rusanu [MSFT] - 04 Apr 2006 05:14 GMT

I'm not sure I understood the question, but I'll try to answer.
When using Service Broker, the 'business transaction' state should be
commited into the database. Service Broker will not deliver uncommited
messages. E.g. a service begins a database transaction, dequeues a message,
processes it's content, updates the business transaction state, sends back a
reply and then commits the database transaction. There is no real
transaction between the services (distributed transaction, two phase commit
etc), only a statefull business transaction that is usually associated with
a Service Broker conversation.

When the services involved are communicating using Service Broker, then
you'll get the reliability guarantee. Other communications frameworks
usually do not offer reliability. If the communication is interuppted if the
connection is closed (i.e. all flavorst of HTTP calls), then you cannot
expect reliability from such communication. Because it benefits from the
persitent storage of a database, Service Broker is guaranteed to resume the
communication if the connection goes down, or even if the server process is
stopped or the host machine is shut down and restarted.

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.

HTH,
~ Remus Rusanu

SQL Service Broker
http://msdn2.microsoft.com/en-us/library/ms166043(en-US,SQL.90).aspx

> Here's the scenario. An item is placed on a queue; this is the end of the
> first transaction. A second transaction begins, a queue processor
[quoted text clipped - 11 lines]
> Thanks,
> Richard

Reply to this Message

Roger Wolter[MSFT] - 04 Apr 2006 05:52 GMT

If you don't commit the transaction until the message processing is done
then the message will be reprocessed if there's a failure in the middle of
processing but there's a chance in this case that the message will be
received and processed twice. Basically, exactly once processing requires
that the processing be transactional - that doesn't necessarily mean Service
Broker but it does mean that whatever is processing the message must support
transactions.

If at least once processing is sufficient for your application then leaving
the transaction open until you know the results of the processing will
provide reliability but you want to be sure the transaction isn't left open
for an indefinite period.

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

> Here's the scenario. An item is placed on a queue; this is the end of the
> first transaction. A second transaction begins, a queue processor
[quoted text clipped - 11 lines]
> Thanks,
> Richard

Reply to this Message