Gotchas

Trying to access an entry you are not subscribed to

Because of the architecture of the shared dictionary, any entry that you have not subscribed to has not been sent to your client. Attempting to access these entries will result in a null pointer exception. The simple fix is simply to add a subscription to this entry.

Setting an entry that you are not subscribed to

Interestingly, Clients can change entries that they are not subscribed to. This allows them to send data to those that are subscribed to that entry, however care must be taken not to request any entry that a client is not subscribed to. It is probably safer simply to subscribe to any entry that you intend to change.

Notifications do not happen in a predictable order

Because of the architecture of the shared dictionary, the order in which notifications and updates occur cannot be predicted. When writing code, ensure that you are careful to only use notifications to collect information that you are sure has already arrived and not entries in the table that are could either be not yet set or contain outdated information.

SQL persistence is very slow

As described in the section on the .persistant tag, it is unwise to continually be writing data to the SQL database. See that section for how to deal with this problem.

Dictionaries can become overwhelmed

.Networking's SharedDictionary uses .NET's ThreadPool for dispatching events. By default, ThreadPool starts with a single thread, and additional threads are added over time, as needed. Your application may benefit from bumping up the minimum number of threads using code like the following: