Last post Jul 06, 2016 05:18 PM by superjose
Jun 26, 2016 03:36 PM|superjose|LINK
My SignalR logic is about to grow a little bit more. I've been using Dictionaries to store temporary data and they've been working wonderfully well: they're fast, and they can be eliminated with ease. Also, no I/O tasks mean that I can leave the server for
more space in case it needs to do a database roundtrip.
I wanted to know, though. If I ever use a backplane and scale out SignalR, how bad will it be to persist data in-memory? I know that synchronizing in-memory objects is also considered bad practice, which will lead me to the database.
In the hypothetical case of a server failure, if the user is disconnected and all the temporary data is lost, it does not matter, because the user will be asked to reload the page and the temporary data will be recreated again without too much trouble.
In that case, should I fall into a Database-only scenario to maintain persistence? Or is it possible to create a single server that could serve as a single unit which would hold all the data in-memory and then distribute it to the other signalR servers?
(I don't know if that is possible using Azure Service Bus)
Jun 27, 2016 08:21 AM|Fei Han - MSFT|LINK
We usually do not persist data in memory, if it is more than one server. According to your description, I think storing data in database is a good and easy approach, each server could access same data from your database.
Jun 27, 2016 05:47 PM|superjose|LINK
Thanks! :D. Will do unit of work with the in-memory solution for now. So in case it scales, we just swap the Dictionary for the in-database solution.
Jul 02, 2016 01:38 AM|hiravebapu|LINK
I am new in signalR development. In my current signalR application, i am using data-tables to hold the data in memory.
Jul 06, 2016 05:18 PM|superjose|LINK
Thanks for the update :)