Question

I understand that a static member will be shared by all users of an ASP.NET website; but in this particular case – that’s exactly what I want.

It’s a private-use webpage I threw together to facilitate web-based chatting between two users. I wanted to avoid persisting data to a database or a datafile, and thought I could store the last X messages in a static concurrent queue. This seems to work great on my development machine.

I’m very inexperienced with ASP.NET, but in all of the examples I’ve found, none use this approach. Is this a bad-practice, are there ‘gotchas’ I should be aware of? The alternative, that I can see, is to use a database. But I felt like it would be more effort and, my guess, is more resources (I figure my ‘buffer’ of messages will take about 40kb of memory and save quite a few trips to the database).

Answer 1

This is perfectly fine as long as your requirements don’t change and you are OK with randomly loosing all messages on server side.

I would slightly refactor code to provide “message storage” interface to simplify testing of the code (with potential benefit in the future if you decide to make it more complicated/persisted/multi-user).

Pro of the static storage approach (or HttpApplicationState):

• no issues with server side storage of the messages – less privacy concerns. Nothing is stored forever so you can say whatever you want.
• extremely simple implementation.
• perfect for IM / phone conversation.
• unlikely to have performance problems in single server case

Cons:

• messages can be lost. Can be mitigated by storing history on the client (i.e. retrieving message with AJAX queries on the same web page)
• require more care if data is sensitive when more users are involved/or application is shared with some other code as static data is visible to everyone. Also not much different from any other storage.
• Can’t be directly migrated to multiple servers/web garden scenario. Really unlikely issue for 2 person chat server.