Sharing Session State

[Guest]

I would like to develop an asp.net Web application using muliple web projects under one solution file and share the session information between web applications( or projects). Is this possible?

 

[CT]

Yes, instead of using Session state, you can use Application state, i.e. you
save to the Application object which is shared among all Web apps on the
server. Alternatively you can implement your own component with shared data.

 

[Guest]

Hi. I've seen this question a bunch of times, and I was interested in it as well, so I tried to pull together everyone's info.


Session state cannot (and should not) be shared because it would be unsecure to do so. In fact, session data isn't completely secure unless you force an SSL connection. Even then, there are issues with older versions of IIS (5.1 and below) where your session state is lost of you browse from an SSL connection to a non-SSL connection, or vice versa.

Using the application object will persist data in the application collection and make it available to all sessions in an app, but there's no way to restrict access.

So, alternatives to sharing session state seem to be:

- Use a SQL database to persist session variables at the end of each session. This allows for access restrictions. You can use the client's cookie as an identifier if you wish. (from 2 seperate posts)

- Implement your own COM component with shared data. Your apps would call that component.

- Use a message queuing system like MSMQ to save or cache data in a "queue which can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine." (from "How can I share cached data between web clients?")

- Use the solution in the article at http://www.asp101.com/articles/jayram/sharestate/default.asp. However, one poster said, "you can do what the article suggests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"

A good topic on MSDN is "State Management Recommendations" at http://msdn.microsoft.com/library/d...vbcon/html/vbconchoosingserverstateoption.asp. It outlines some of the options above.

 

[Guest]

Hi. I've seen this question a bunch of times, and I was interested in it as well, so I tried to pull together everyone's info.


Session state cannot (and should not) be shared because it would be unsecure to do so. In fact, session data isn't completely secure unless you force an SSL connection. Even then, there are issues with older versions of IIS (5.1 and below) where your session state is lost of you browse from an SSL connection to a non-SSL connection, or vice versa.

Using the application object will persist data in the application collection and make it available to all sessions in an app, but there's no way to restrict access.

So, alternatives to sharing session state seem to be:

- Use a SQL database to persist session variables at the end of each session. This allows for access restrictions. You can use the client's cookie as an identifier if you wish. (from 2 seperate posts)

- Implement your own COM component with shared data. Your apps would call that component.

- Use a message queuing system like MSMQ to save or cache data in a "queue which can either
reside locally or on a dedicated server. Any application can read the queue
once it knows the path to the queue - it typically does
You can store the message in any format from text, to
full blown datasets or custom objects. You can think of the msmq as a robust
caching strategy over a network. It's a good approach because the msmq can
be configured to be fail safe (survive reboots), back up messages, provide
confirmation etc. In addition, msmq can be programmed in a line or two, but
it does require the msmq service to installed and running on the machine." (from "How can I share cached data between web clients?")

- Use the solution in the article at http://www.asp101.com/articles/jayram/sharestate/default.asp. However, one poster said, "you can do what the article suggests without
the massive delete, edit the .webinfo file crap if you set up the parent app
and make the other "apps" subdirs of the parent app (importing, if child
apps already completed). This is really a non-solution for most of us, as
you are essentially killing the child apps and making a single parent app
with all of your applications. You cannot set up the application on a unique
CName, like app1.mydomain.com, as it is tied to the other apps*. Yuck"

A good topic on MSDN is "State Management Recommendations" at http://msdn.microsoft.com/library/d...vbcon/html/vbconchoosingserverstateoption.asp. It outlines some of the options above.