Best way to fire and forget

[monkeymagix]

Hi

I have a Betfair BOT that once every few seconds or so grabs the prices of all runners in all markets (UK,IRE,FRA etc) and then saves them to the DB.

However as the stored proc that is called does quite a bit of work including looking for possible trades and moves in the market I want to be able to "fire and forget" e.g not wait for the response of the stored proc before moving onto the next record as that slows things down and I need to be moving quickly.

What is the best method of calling a stored proc in C# and NOT waiting for the result, returning a success status, and then moving onto the next record.

I'd like to be able to just quickly loop through my object list of selections and call some method that does the DB call without waiting for the response before moving to the next item in the loop.

It's a windows service running from my PC at the moment in C# 4.5. The calls to collect prices are fired from timers that wait X seconds before running the relevant code to collect the API data from Betfair and get their current prices etc.

I was thinking about using something like

Parallel.ForEach(sqlRecordset.AsEnumerable(), recordsetRow =>
{
// get data for selection
// call DB to save without waiting for response / success/failure status
}

But I don't know if this is the best approach or not.

Ideas?

Thanks in advance for any help.

[bnl]

Split the code into two or more services, one that polls bf and stores the result in db,
And one that has your logic, and reads result from db. Also have a pipe or socket between them so the fetcher can wake the consumer after each commit.

Or use threads, but i think that is what you due with parallels. But i wonder if you do not need
One db connection for each thread then. And in your sample , would you not need one connection per
Row? Commit/rollback is singleton on a connection....

I have 1 fetcher and many consumers, using pipes. However, not a consumer per resultrow,
But a consumer per business logic i use.

Also, it is nice for simulations to have data in a format that I understand. I never managed to interpret the bf historic data in a useful way

/Björn