January 19, 2003 at 7:32 pm
If you are using a non 'sa' account for the SQLServer based Session State configuration within ASP.net, you may notice that you loose the necessary permissions within tempdb in order to retrieve session data whenever the server restarts.
In order to get around this, you needn't bump up to the 'sa' account ...
Firstly, modify the startup stored procedure : ASPState_Startup within the master database ...
CREATE PROCEDURE ASPState_Startup
AS
EXECUTE ASPState..CreateTempTables
EXECUTE tempdb..addASPNETSessionUserRoles
RETURN 0
GO
exec sp_procoption N'ASPState_Startup', N'startup', N'true'
GO
Secondly, because when SQL Server is restarted it re-creates the tempdb table from the 'model' reference ... you need to create a new stored procedure within the model database called 'addASPNETSessionUserRoles' :
CREATE PROCEDURE [dbo].[addASPNETSessionUserRoles] AS
exec sp_grantdbaccess 'aspSession', 'aspSession'
EXEC sp_addrolemember 'db_datareader', 'aspSession'
EXEC sp_addrolemember 'db_datawriter', 'aspSession'
GO
When the server restarts, this new SP is included within the tempdb database ready for the startup SP within the master database to execute it and hence add your aspSession user account & roles into the tempdb database.
I think its better to add the stored procedure into the model database than add a user into it. That way you are not adding a new user to every new database that gets created, just the stored procedure, and that only gets called if you want it to. Even then the aspSession account should be a standard user account, nothing special.
January 22, 2003 at 8:00 am
This was removed by the editor as SPAM
January 22, 2003 at 1:51 pm
Not bad. Havent spent much time in ASP.Net yet, have seen the demo's of the sql persistence, again, not bad. Using tempdb aint my favorite solution, is it configurable?
Andy
January 22, 2003 at 2:05 pm
quote:
Not bad. Havent spent much time in ASP.Net yet, have seen the demo's of the sql persistence, again, not bad. Using tempdb aint my favorite solution, is it configurable?Andy
http://www.sqlservercentral.com/columnists/awarren/
It's (ASP.Net Session State) configurable to a certain degree, but not to the extent that you can exclude the use of tempdb when using SQL Server based sessions. I prefer this solution as its web farm friendly, however in my own custom session state implementation that I did for use in ASP3, I had a SQL server based session utility that included the use of collections that I particularily like to use for shopping baskets !! I'm not sure what you can store in an ASP.net SQL server based session, maybe you can store a collection. Probably can.
January 22, 2003 at 2:06 pm
Andy, there are three options for storing session state in asp.net now.
1) In local memory (Same old nasty non-farmable method)
2) In memory on a central server. (I Prefer this method)
3) In the database.
As to your question, I am pretty sure that you can do this. If you have .Net look at the Framework\*Version*\InstallSqlState.sql
file. By modifying it from the temdb to some other DB it will most likely work the same.... I will try this soon, unless someone else does.
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Tim C //Will code for food
January 22, 2003 at 2:11 pm
quote:
Andy, there are three options for storing session state in asp.net now.1) In local memory (Same old nasty non-farmable method)
2) In memory on a central server. (I Prefer this method)
3) In the database.
As to your question, I am pretty sure that you can do this. If you have .Net look at the Framework\*Version*\InstallSqlState.sql
file. By modifying it from the temdb to some other DB it will most likely work the same.... I will try this soon, unless someone else does.
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Any 'In Memory' based session state isn't scalable in a true sense, therefore I would always recommend the SQL Server based route for a heavily used site.
January 22, 2003 at 2:16 pm
quote:
Andy, there are three options for storing session state in asp.net now.1) In local memory (Same old nasty non-farmable method)
2) In memory on a central server. (I Prefer this method)
3) In the database.
As to your question, I am pretty sure that you can do this. If you have .Net look at the Framework\*Version*\InstallSqlState.sql
file. By modifying it from the temdb to some other DB it will most likely work the same.... I will try this soon, unless someone else does.
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
I think this is a great idea, and would remove the need for a work-around. Get to it, share it !
January 22, 2003 at 2:28 pm
The #2 solution even tho in memory is in memory on one server. So farming is viable without having to "STICK" a user to a server for the duration of their connection(which violates farming principles anyway). The IIS server makes a request to a server running the ASP session state service, and it serves up the same as if you had a DB. Reasons I like #2 best :
1) No dependency upon a DBMS. Not everone has SQL Server.
2) Reduces load upon SQL Server, and connections, which are valuable.
3) Can be run on a low end desktop.
This is just my preference, and do not recommend this over the DB in any way. I think they both work fine and are both viable. So do what someone smarter than me suggested once. Try them all out, and pick the one you like. (I won't mention what that statement was originally in reference to..)
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Tim C //Will code for food
January 22, 2003 at 2:35 pm
Well, MSFT already had the answer on how to use a db other than temdb, just needed to dig deeper.
HOW TO: Configure ASP.NET for Persistent SQL Server Session State Management
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q311209
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Tim C //Will code for food
January 22, 2003 at 2:38 pm
Here is a nice article on asp.net session state : http://www.eggheadcafe.com/articles/20021016.asp
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Edited by - tcartwright on 01/22/2003 2:39:13 PM
Tim C //Will code for food
January 22, 2003 at 2:43 pm
Obviously, if you are not in a heavily loaded environment, you can do whatever you choose.
However, just to reiterate and extend, the SQL Server based option works in the heavily loaded environment because :
a) Not memory based;
b) Can work in a web farm environment with either a cookie based or cookieless sessionID.
c) Your sessionID is not STUCK to any particular web server machine because the sessionID is stored in SQL, not on the machine.
Therefore this is a still a preferable solution, although it must be admitted that it may be slightly slower than a memory based solution.
Hope this helps.
January 22, 2003 at 3:14 pm
quote:
a) Not memory based;b) Can work in a web farm environment with either a cookie based or cookieless sessionID.
c) Your sessionID is not STUCK to any particular web server machine because the sessionID is stored in SQL, not on the machine.
Look up StateServer in :
http://www.eggheadcafe.com/articles/20021016.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspnet/html/asp12282000.asp
A StateServer will allow farming without a sticky bit set and with either a cookie based or cookieless environment. Lastly it is faster than the SQL Server solution expecially when start storing objects in the session state. Objects stored in Session State now have to support serialization.
Serialization
http://msdn.microsoft.com/library/en-us/cpguide/html/cpovrserializingobjects.asp
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Tim C //Will code for food
January 22, 2003 at 3:29 pm
But, the StateServer solution runs in memory which is a finite resource : The biggest problem with ASP 2/3 session based data, especially objects, and therefore the biggest problem with StateServer.
This has been a great discussion for me, as have learned about the existence of a new ASP.net SQL Session script that doesn't use tempdb, and it's from Microsoft. Thanks TC.
rgds,
Cam, Effective Web, UK.
January 22, 2003 at 3:37 pm
Thanks, and you are correct a HEAVILY used site IMHO would quickly fill up the memory on a StateServer especially if objects were being serialized into it. What I would like to see is some kind of study as to how much load a StateServer with n meg of memory could handle. Take for example a site where users enter their address information in some sort of a sign up, what would be the effect of memory for storing that data on the StateServer? What about serializing the a CAddress object and putting that into memory X n users.
Tim C.
//Will write code for food
One Windows to rule them all, One Windows to find them,
One Windows to bring them all and in the darkness bind them
In the Land of Microsoft where the Shadows lie.
Tim C //Will code for food
January 22, 2003 at 3:46 pm
We rolled our own recently using SQL - we needed a way to map session vars between asp and aspx sessions. Worked out pretty well.
Andy
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply