You could use a concurrent queue, if you're using .NET 4.0 or higher:
Concurrent Queue (MSDN)
This is a thread-safe way of using a queue, which then could be accessed at a desired time.
Edit:
Example:
This would be a wrapper for the queue:
public static class RequestQueue
{
private static ConcurrentQueue<int> _queue;
public static ConcurrentQueue<int> Queue
{
get
{
if (_queue == null)
{
_queue = new ConcurrentQueue<int>();
}
return _queue;
}
}
}
Then you could set up your web api like this (this example stores integers for the sake of brevity):
public class ValuesController : ApiController
{
public string Get()
{
var sb = new StringBuilder();
foreach (var item in RequestQueue.Queue)
{
sb.Append(item.ToString());
}
return sb.ToString();
}
public void Post(int id)
{
RequestQueue.Queue.Enqueue(id);
}
}
If u use this example you'll see that the queue holds the values across multiple requests. But, since it lives in memory, those queued items will be gone if the app pool is recycled (for instance).
Now you could build in a check for when the queue holds 10 items and then save those to the DB, while creating another queue to store incoming values.
Like so:
public static class RequestQueue
{
private static ConcurrentQueue<int> _queue;
public static ConcurrentQueue<int> Queue
{
get
{
if (_queue == null)
{
_queue = new ConcurrentQueue<int>();
}
if (_queue.Count >= 10)
{
SaveToDB(_queue);
_queue = new ConcurrentQueue<int>();
}
return _queue;
}
}
public static void SaveToDB(ConcurrentQueue<int> queue)
{
foreach (var item in queue)
{
SaveItemToDB(item);
}
}
}
You need to clean this up a bit, but this setup should work. Also, you might need some locking mechanism around the dumping of the queue to the DB and creating a new instance. I would write a Console app with multiple threads that access this Queue to test it.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…