Data Access on Amazon EC2 Cluster

[Daniel]

Hi,

I am trying to figure out if I can use the Data Access engine with L2 caching on a cloud application designed for Amazon that will entail autoscaling.  NLB and MSMQ are not optimal solutions in this environment.  At least from what I can figure, the easiest thing to do would be to disable the L2 cache, though I would hate to go without it.  Retaining it means using MSMQ which is old tech and doesn't fit well into our architecture, at least that I can tell. 

I know one of the first responses here is to use sticky sessions.  Sticky sessions do not work well with corporate accounts as these guys have an army of proxy servers and a users request may be routed dynamically through any of them.  I've been there already on a previous project that the solution (outside of Amazon at the time) was to use MSMQ to sync the servers.

Wouldn't it be grand if I could have my autoscale on Amazon and still leverage L2?  Is this a dead-end?

-Dan

 

[Thomas]

Hi Dan,

out of the box we provide synchronization between the local second level caches with MSMQ. We use MSMQ for its ability to have a reliable multicast; that is, front ends and back ends can join/leave the same multicast group and post messages back and forth to the entire group. Principally we only post evict messages, which are short messages that only notify to remove entries from the cache. We never populate a cache via messages because that is done locally as a side product of the normal reading activities.

We are aware that MSMQ might not be a perfect solution to Amazon. I've put together a git  project under

https://github.com/tkcode123/CustomSecondLevelCacheCluster

that shows how to implement a custom second level cache cluster eviction mechanism with TCP or RDP.
This solution provides you with a starting point for your own implementations.
There will be no official support for this project from Telerik/Progress.

I kindly ask you to contribute changes/improvements back so that other customers could benefit from it. (The license does not require this.) 

Regards,
Thomas
Telerik