Hi Greg,

I'm in a situation where I need to keep a data structure synchronized across nodes.

My first thought was to use things like they are for the distributed cache, and just update my datastructure when a new object is sent, or deleted (etc.).

My next thought was to implement a custom DistributedCache class, and just handle the update of the other nodes like you do in your DistributedCache, with sendCacheItemToClusterMembers(). Not all of the DistributedCacheItemInfo object would apply, but I could use what I needed.

I guess what I am asking is, is there a more generic way to send items to all of the other running nodes that I could (or should) use? Or in another form, what would you recommend in this situation?

Thanks,
Darren

I think you want to use the distributed cache....see the MoreInterestingTestHarness ServiceA for example, plus tutorial. You just do not need to actually cache the object, but even if you do, no harm I suppose. You write the method that gets called, so I am sure you can easily adapt for your purpose. For speed, you would want to use a tcp-binary binding on this service (reduces by large margin network utilization and serialization CPU costs). It already has the threading and retry logic built in; hence why I think you can leveredge without re-inventing the wheel.

-Greg

---

Greg Leake, Microsoft

The two built-in ways are either CustomAction (I provided code in another post on this forum); or the distributed cache (node DC). With custom action, you are limited to passing in a List<String>; but need not define any contracts (data or service); with distributed cache, you must provide a data contract and service contract; define in ConfigWeb a virtual host and endpoint for the contract...the tutorial shows how this is done....then you can pass any arbitrary objects (as long a serializable) between nodes.

-Greg

---

Greg Leake, Microsoft

Hi Greg,

Thanks for the response.

I feel like an idiot, but I cannot find the post around the CustomAction, but since I would be limited to aList<String>, I guess it doesn't matter to much ;)

I looked at the distributed cache class, and although it would work, it does things I just don't need. This isn't a problem per se, that's why I asked the question to see if there was another way.

Each running node has a list of objects, and it is the services job to maintain this list. I just want to make sure that each running instance has the same list, no matter who gets the actual call to add the object to their list.

I am sure I can use the DC portion, and just grab that object when the service sees it and add it to it's list. I really don't need the System.Web.Caching mechanism for this case, so my thought was to write a class that handled the passing but did not perform caching.

Anyhow, I was just kicking this around before I really have to think about the implementation.

Thanks,
Darren

I think you want to use the distributed cache....see the MoreInterestingTestHarness ServiceA for example, plus tutorial. You just do not need to actually cache the object, but even if you do, no harm I suppose. You write the method that gets called, so I am sure you can easily adapt for your purpose. For speed, you would want to use a tcp-binary binding on this service (reduces by large margin network utilization and serialization CPU costs). It already has the threading and retry logic built in; hence why I think you can leveredge without re-inventing the wheel.

-Greg

---

Greg Leake, Microsoft

Hi Greg,

Sounds good, this was what I was looking for. I'll be working on this on Monday, to add cluster/failover ability to our event framework.

Thanks!
Darren

Hi Greg,

Because each cache is really a local cache, this end up being a pita to implement. I was able to develop a DC node to pass info around, but took quite a bit of tweaking on my service implementation to expose the List in a way in which it could be added to. While I think I can now keep cache's synchronized while they are both running, if I have a service up and running which contains a list of X objects, when i spin up a new service to help handle part of the load, I will of course not automagically sync with the other local cache already floating out there. While any future additions/subtractions are handled, the past is not.

Which brings me to Velocity. I think what I may do instead is implement a Velocity distributed cache, and then just have clients in the service that use the list from here. That will still give me the option of a local level of the cache, but most importantly all of my distribued services will be using (virtually) the same list without me having to synchronize it myself.

Thanks for the help!

Darren

This makes sense. I have not tested Velocity yet; but you are right, this would likely be the better approach for your scenario, unless you store your list in a database initially, and update the DB on list additions. In this way, a new node would retrieve/cache the current list, then send to other nodes; reads could still come from the cache. I'll want to start playing with Velocity soon, though.

-Greg

---

Greg Leake, Microsoft