Communicating between ASP.NET applications on the same machine

I have a situation where information about a user is stored in the web application cache and when that information is updated in one application - I want to notify the other applications (running on the same machine) that the data should be removed from it's cache so it can be refreshed. Basically I need to keep cached data in sync across multiple asp.net applications.

I have started down the path of using a central web service to help coordinate the notifcations but it is turning out to be more complex than I think it needs to be.

Is there a way that one asp.net application can easily reach across to another on the same box to clear an item from the cache?

Is there a better way to achieve shared cached information than using the application cache?

I really want to create a way for apps to communicate in a loosely coupled way - I looked at nservice bus but the dependency on MSMQ scared me away - my client has had bad experiences with MSMQ and does not want to support an app that requires it.

Suggestions? Michael

Microsoft suggest WCF instead of remoting. Personally I'd not want to do COM unless there was no other option (and services are clearly an other option)

Murph 2010-02-16 16:58:29

Remoting seems a very bad idea to me. What should happen if one of the applications goes offline? What should a calling application do when the receiving application doesn't respond right away. The solution will be fragile or it will at least be hard to build it in such a way that is isn't fragile.

Steven 2010-02-16 17:01:41

@Hogan: I bet performance. All applications are always up to date when no cache is used, but in that case the data source has to be queried on each request, which might give performance problems.

Steven 2010-02-16 17:04:00

I am actually storing a custom user principal in the cache - process for initialiizing the principal is pretty data intensive so I cache it for 20 mins so subsequent requests do not have to hit the db. I wonder if using the sql cache dependency would work for this situtation.

MIantosca 2010-02-16 17:05:26

@Mlantosco : I'm sure it would -- I've used something similar for a SSO custom enhancement once, it worked well. You are in a good spot with the custom principle because you have already customized the authentication system...

Hogan 2010-02-16 17:18:03

@Steven : Yep, I'm sure the OP's hope is to have good performance. But at some point you end of having not worth it returns. Point to point communication nets will drive you crazy, you want a single point of control or a messaging system. SQL is the perfect choice if he is already using it.

Hogan 2010-02-16 17:20:23

@Hogan - I am looking at cache dependency as an option now - would I be clearing all of the principals from the cache if something changed or can I limit it to just one principal? I assume that if I want it to be a targeted invalidation - that would require n dependencies for n principals - that seems like it might not scale well.

MIantosca 2010-02-16 17:25:57

True, we did not expect principles to change often in our system... how often do you expect changes? -- you are already clearing every 20 mins anyway...

Hogan 2010-02-16 18:00:32

@Hogan - they don't change that often but when they do we want the change to take effect almost immediately. An action in one application (like a purchase of a subscription) will assign a role (and in turn give the user permissions) in another application (like the online learning tool.) We want the user to immediately be able to access something they just purchased.

MIantosca 2010-02-16 19:19:27

what about this idea: serialize the userprincipal (or store it as a binary object), store it in the database and use the database as the shared cache for security information. It would include an expiration datetime that can be checked to see if it needs to be refreshed.

MIantosca 2010-02-16 19:35:30

@Mlantosca: Yes, I think this is on track, because you only need to "refresh" to grant new access. Users that have access don't matter, you can cache those like crazy. This is only the sub-set of people who don't have access before trying to look at something they might now have rights to see. If you have so many subscriptions rushing in that you get a bottle neck on new subscribers checking for access... well :D You can spend some money to make a better solution, or toss hardware at it, or something.

Hogan 2010-02-16 21:36:38

@Hogan - actually I am only putting the serialized principal into the db 'cache' when they first login to one of the applications. All subsequent page requests by the same user in any app will find the principal in the cache. I already have code for removing user principals from the memory cache when a new role is assigned - now all I need to do is redirect that call to delete the principal from the db 'cache' instead.

MIantosca 2010-02-16 21:53:24

@Hogan - thanks for helping out with this - I think this solution will work great.

MIantosca 2010-02-16 21:55:59

@Mlantosca - Your welcome, glad I could be of help.

Hogan 2010-02-16 22:25:47

I do not think AppFabric (which velocity is now part of) has been released - I would love to use a distributed cache like velocity but my client will not go for non-RC/RTW/RTM code for something this central to all their apps. I think it is still in CTP

MIantosca 2010-02-16 19:27:40

thanks for the references - I will take a look. I agree the distrbuted cache is the ideal solution and will see if I can get my client to agree that we need to implement one.

MIantosca 2010-02-18 20:43:37

ansaurus

tags:

views:

answers:

Communicating between ASP.NET applications on the same machine

related questions