SQL Server Service Broker

Discussion in 'Automated Trading' started by nitro, Oct 23, 2010.

  1. nitro


    Has anyone ever used SSSB for Order Management persistence and Asynchronous messaging?
  2. januson


    Yes I have thought about it, but I realized it was too slow and the architecture was too stupid demanding Sql Servers everywhere.

    Are you developing in c#?
  3. nitro


    Well, it would not be for a high frequency system, which comprises maybe three people on ET. It makes zero difference that it takes an extra 50 milliseconds, if that, to process an order that is being updating less than say 200 times a day.

    Yep, developing in C#.
  4. Iti s a great API to use, but it is not made for anything like order handling. I can see it for accounting etc. (backend). The main problems you face are along:

    * Performance. It can be slow at times. In the timeframe of order submission.

    * You need to handle outdated orders. Elements in service broker stay there until processed. Your order submitter crashes - half an hour it is up - it will continue woirking on orders in the queue.

    As I said - great for stuff going to the backend (fills etc.) where both elements are not disadvantages.
  5. januson


    If you are interested in a broker with transactional safety/ concurrency then consider a Service Broker in .NET for instance MassTransit or NServiceBus.

    They are great frameworks and can handle a high throughput. I recommend such instead of going with SSSB that as previously mentioned is carrying a strange over-exposed enterprise soul.
  6. januson


  7. nitro


    The problem with MSMQ is that there is a bunch of things that needs to be gotten just right, e.g., how transactions are handled, how exceptions cause rollbacks, how to stop rolling back endlessly (poison messages), how to integrate with long-running workflows so that the state management boundaries line up, etc. AFAIK, MSMQ is a lite messaging system.