Developer forum

I haven tried it yet, but we've talked about setting up a solution in a clustered environment. It seems as session state only affects where session information and provides an alternative to storing in virtual memory, so my guess, and I'm no expert on this, is that it should be possible.

Anyone?

Sorensen wrote:

I haven tried it yet, but we've talked about setting up a solution in a clustered environment. It seems as session state only affects where session information and provides an alternative to storing in virtual memory, so my guess, and I'm no expert on this, is that it should be possible.

 

Anyone?

My thoughts are the same. But one small thing I know that will have an effect is if you store an instance of a class, which is not marked as "Serializable", in session. It will throw an exception.

/ Jacob

Just did a bit of snoozing around here and in Host Nordic. Actually a inhouse grassroot movement made an attempt with this at one point, but due to the serialization issues it had to shut down. All objects stored in sessions along with object used as properties in session stored objects need to be serializable as well, which is not the case. There's also some overhead in serializing and dezerializing objects using this approach.

But I found out that we have succesfully made a setup with NLB - could that be of interest?

Sorensen wrote:

Just did a bit of snoozing around here and in Host Nordic. Actually a inhouse grassroot movement made an attempt with this at one point, but due to the serialization issues it had to shut down. All objects stored in sessions along with object used as properties in session stored objects need to be serializable as well, which is not the case. There's also some overhead in serializing and dezerializing objects using this approach.

 

But I found out that we have succesfully made a setup with NLB - could that be of interest?

True... but you should clean up some of the stuff you store in session ;) The serializing and dezerializing overhead is minimal I believe, not even noticeable. But I do not know everything the software needs to do so you might well have a very good reason for not changing it from InProc. My problem is just the loss of session data which I would really like to keep :)

When you mention a setup using NLB... what do you mean?

Regards Jacob

Clean up? Hm... I assume you're working on a project that will actually cover the costs of man hours since you're mentioning this;)

NBL - Network Load Balancing is a clustering technology that allows you to balance the load by routing traffic to a specific host in a cluster. When a session starts, it's assigned to a specific host that hosts this session throughout its lifetime. An other session is then assigned to a different host and so you balance the load betwenn a range of servers.

There's a white paper on NLB here: http://technet.microsoft.com/en-us/library/cc758834.aspx

Hi Jacob

If it is a matter of not loosing info when loosing a session, save the data in a database using the ASP.NET SessionID (same used by state server), or give all sessions an ID of some sort, i.e. GUID, save it in a cookie and use that for persisting data in the database.

Sorensen wrote:

Clean up? Hm... I assume you're working on a project that will actually cover the costs of man hours since you're mentioning this;)

 

NBL - Network Load Balancing is a clustering technology that allows you to balance the load by routing traffic to a specific host in a cluster. When a session starts, it's assigned to a specific host that hosts this session throughout its lifetime. An other session is then assigned to a different host and so you balance the load betwenn a range of servers.

 

There's a white paper on NLB here: http://technet.microsoft.com/en-us/library/cc758834.aspx

Hehe... no my projects won't cover much :) but I hope you will clean up the "Dublin Core" part some day. It sure does save a lot of empty XML in session... 5000 small pages dynamicweb site will explode the size of the w3wp process. But I guess we just need more RAM ;)

I will have to do a bit of research on the NLB matter to see if this will help me. Thanks.

Sorensen wrote:

Clean up? Hm... I assume you're working on a project that will actually cover the costs of man hours since you're mentioning this;)

 

NBL - Network Load Balancing is a clustering technology that allows you to balance the load by routing traffic to a specific host in a cluster. When a session starts, it's assigned to a specific host that hosts this session throughout its lifetime. An other session is then assigned to a different host and so you balance the load betwenn a range of servers.

 

There's a white paper on NLB here: http://technet.microsoft.com/en-us/library/cc758834.aspx

I'm not sure how NLB relates to what Jacob is asking. The reason for using State Server is neither scaling nor availability, it's simply a matter of a durable persistance of session state across appdomain restarts. Since the appdomain will restart each time a new dll is uploaded, worker recycles, critical errors etc, it's a rather common event that will cause user irritation.

The biggest issue however is in developer productivity. Loosing session state on each build is a major hassle.

np wrote:

Hi Jacob

 

If it is a matter of not loosing info when loosing a session, save the data in a database using the ASP.NET SessionID (same used by state server), or give all sessions an ID of some sort, i.e. GUID, save it in a cookie and use that for persisting data in the database.

Hi Nicolai,

Saving data in the database is a rather ugly workaround of sessions restarting. Do you suggest that one reads the old session data (stored in the DB) and repopulates the newly created session? Surely it would be more appropriate to find a solution so state server / sql server sessions are supported out of the box?

Oh, sorry, I didn't get that from the "some of the benefits" specification in the original post. My bad:)

You're making a good point, but it will be difficult giving this top priority in the current version. Too much effort at too little benefit. We're talking massive changes thoughout the application.

This is of cause just my immediate impression. If you have a differend opinion, we're always eager to learn new things.

np wrote:

Hi Jacob

 

If it is a matter of not loosing info when loosing a session, save the data in a database using the ASP.NET SessionID (same used by state server), or give all sessions an ID of some sort, i.e. GUID, save it in a cookie and use that for persisting data in the database.

Hi Nikolaj,

yes this is the core of my problem. But if I am to do what you suggest I would then have to handle all the data that Dynamicweb stores on it's own? What I wish to keep, is the login data of dynamicweb extranet.

Regard

Jacob

The "Remember me/auto login" feature?

Sorensen wrote:

The "Remember me/auto login" feature?

If it is possible to isolate the "auto login" part then yes it would solve part of my problem. But I do not want the page to remember the user and there by exploid his account to other users using that machine.

The Dynamicweb.Notifications.Standard.User.OnAfterLogin notification allows you to hook on to the process, where the user logs in. Here you could store som additional information to his AccessUser profile and dump a cookie containg this information. Then, using a one of the notifications in the Dynamicweb.Notifications.Standard.Page class, using a Page Template Extender, or Default.aspx you can check to see if Dynamicweb.Frontend.PageView.Current().User.LoggedIn is false, and if so load the information from the cookie, load the user's login information from AccessUser and log the user on using the ExtranetLogin method of the Dynamicweb.Security namespace.

Is this what you need? I wrote an article on logging on a while back. You may find it useful: http://developer.dynamicweb.dk/default.aspx?id=16918&action=ShowArticle&ArticleID=141

Sorensen wrote:

Oh, sorry, I didn't get that from the "some of the benefits" specification in the original post. My bad:)

 

You're making a good point, but it will be difficult giving this top priority in the current version. Too much effort at too little benefit. We're talking massive changes thoughout the application.

 

This is of cause just my immediate impression. If you have a differend opinion, we're always eager to learn new things.

Out of curiosity, what objects are you storing in session that can't be serialized?

PageView, nested objects, ecom context. There are probably more.

Sorensen wrote:

PageView, nested objects, ecom context. There are probably more.

But if these are your objects, is there anything holding you back from marking them with ISerializable? It should only be a problem if you're referring to BCL classes that are not serializable. And as of .NET 3.5SP1 all BCL classes with default constructors are serializable, no matter if they implement ISerializable or not, so the chances of referencing a non serializable BCL class is rather limited.

If it aint broken - don't fix it.

And yes - we could mark objects as serializable - but its the never ending story:

We store an object in session - so we mark that as serializable. That object has a property, say a collection of some other objects - then that collection and those objects also have to be serializable - and before we know it - everything needs to be serializable, and not all things can be...

I've been down that path before as a test - don't want to go there again.