losing sessions when running in StateServer mode

[3P]

I had a situation where I couldn't use the session-id, which would have
been concatenated at the end of a session custom object name that needed
to be passed around from page to page. The reason I couldn't use the
session-id is another story, and I don't want to get into it.

And my solution was to ToString() a Guid and concatenated the GUID to
session custom object name. So the application started up on a certain
page when doing a creation of user information, and it started-up on
certain page when maintenance was being done to the existing user
information.

The original GUID assigned had to be passed from page to page to
construct the session object name for the custom object to set/get
session object.

How I did it was the two pages that were used for create/maint would
initially get a new GUID at page-load !postback. It would save the
string Guid to a hidden field, which was on all the pages for this
application. As each page did a redirect to another page, the GUID was
taken from the hidden field and passed on the URL.

The pages would determine at their page-load if it was a postback or
not. It was not a postback (redirect from another page), the page would
querystring for the GUID on the URL and save it to its hidden field for
the GUID. If it was a postback then, the page would go to the hidden
field to get the GUID, because the URL no-longer had the GUID on the URL
on postback. In either case, I always had the initial GUID that was
trapped on my two start pages to be passed around to the other pages to
construct the session variable name to get/set.

Even if the page timed-out, the GUID was not lost as the page kept GUID
using a hidden field state.

If one is not inclined to use a base page to hold Session-ID, one could
use what I have talked about to trap the Session-ID and pass it around
and not loose it.

I'm not sure how is that different than storing that GUID in session.
If session times out You will still loose that hidden field GUID because
You will be
redirected to login page.

And what if someone gives someone else link with his GUID in it? Will that
other person
steal the object? Or will they concurently use same object? What when
someone changes
the GUID in address by accident?

 

[Mr. Arnold]

Because this is custom logic. Not typical session usage.

Can I ask if You did some performance measuring? What I find weird is
spawning another thread in
PageUnload. Thus You use two worker threads for each client and that will
decrease performance of
application.

It was an async thread with no return. So the pages were not waiting for a
return, which was using an async WCF Web service on the back-end, a Web
service farm. There were no performance issues. The main point was to get
the object back into session if it was lost -- no matter what caused the
session to be lost with IIS resets being done 5 to 6 times throughout the
day, which was used worldwide 24/7. It was a critical application within
the enterprise level solution, but it was not a high usage application
within the total enterprise solution.

 

[Mr. Arnold]

I'm not sure how is that different than storing that GUID in session.
If session times out You will still loose that hidden field GUID because
You will be
redirected to login page.

I am confused here. Were you working on this application? I don't recall
seeing you anywhere. You have no clue as to what you're talking about as to
how the total enterpeise level application worked and the specifications
that were given. This was not a situation where the user was sent to the
login page or any other page.

And what if someone gives someone else link with his GUID in it? Will that
other person
steal the object?

It didn't happen. They didn't give out the URL for this closed to the public
Internet solution.

Or will they concurently use same object? What when someone changes
the GUID in address by accident?

If they were dumb enough change the GUID on the URL, then it was going to
blow because, it couldn't find the session object based on the variable name
having part of the guid as the name, and they were not dumb enough to change
the other parms on the URL either. If this was a problem, then I wouldn't
have gotten the specifications to do it what I did nor the approval.

I don't recall you creating specifications nor did I see you in the
development and testing phases either.

Gee! You need to stick to what you know, and not projecting as to what you
think should be happening. You were not there. I was there.

 

[JK]

Brian Cryer a écrit :

My feeling is that either:
1. Its an application issue - something is explictly changing the
session ID or the cookie ("ASP.NET_SessionId" I think) that .NET uses to
keep track of the session ID.

Right! I've found a hack in the code trying to set the timeout for this
cookie. I've removed it and it seems better so far. I'm still testing.

Many thanks for all Brian

JM

 

[3P]

I am confused here. Were you working on this application? I don't recall
seeing you anywhere. You have no clue as to what you're talking about
as to how the total enterpeise level application worked and the
specifications that were given. This was not a situation where the user
was sent to the login page or any other page.


It didn't happen. They didn't give out the URL for this closed to the
public Internet solution.


If they were dumb enough change the GUID on the URL, then it was going
to blow because, it couldn't find the session object based on the
variable name having part of the guid as the name, and they were not
dumb enough to change the other parms on the URL either. If this was a
problem, then I wouldn't have gotten the specifications to do it what I
did nor the approval.

I don't recall you creating specifications nor did I see you in the
development and testing phases either.

Gee! You need to stick to what you know, and not projecting as to what
you think should be happening. You were not there. I was there.

Now I know for sure. You are plain dumb. I kindly asked and You are
attacking me.

And BTW this is very ugly solution. You don't know a lot about ASP.NET as
You shown in this thread.

 

[3P]

It was an async thread with no return. So the pages were not waiting

for a return, which was using an async WCF Web service on the back-end,
a Web service farm. There were no performance issues. The main point was
to get the object back into session if it was lost -- no matter what
caused the session to be lost with IIS resets being done 5 to 6 times
throughout the day, which was used worldwide 24/7. It was a critical
application within the enterprise level solution, but it was not a high
usage application within the total enterprise solution.

Well every thread is async.

I know page wasn't waiting for thread to finish, but still two worker
threads
were used for every page load/unload. But You said it wasn't high usage
app. That's
probably why You didn't see performance penalty.

 

[3P]

I have used it in a couple of shops. It was OK, and I didn't really see
any performance issues using a SQL State server.

Because that was small app. It is a lot slower. And it doesn't scale well.
MS words
if You don't believe me.

You can make it work a bit faster if You turn off session on pages that
doesn't
need it or set read only session access mode. On large app You will
probably have to write
custom code and use many session databases on many servers.

 

[Mr. Arnold]

Well every thread is async.

I know page wasn't waiting for thread to finish, but still two worker
threads
were used for every page load/unload. But You said it wasn't high usage
app. That's
probably why You didn't see performance penalty.

I don't think it would have made a difference if it was a high usage app for
the simple fact that it was using an async WCF Web service to persist the
serialized object on the back-end. It was used often enough along with
another application within the solution that was using the same type of
technology.

 

[Mr. Arnold]

Now I know for sure. You are plain dumb. I kindly asked and You are
attacking me.

I am not here to hold your hand nor did you work on the project. Those are
the facts that can't be ignored.

>
And BTW this is very ugly solution. You don't know a lot about ASP.NET as
You shown in this thread.

Yeah right!!!!!! And I am sure you no nothing about OOP, ASP.NET WCF Web
services and ADO.NET Entity Framework used in n-tier technology.

 

[Mr. Arnold]

Because that was small app. It is a lot slower. And it doesn't scale well.
MS words
if You don't believe me.

Here you go projecting again I see.

You can make it work a bit faster if You turn off session on pages that
doesn't need it or set read only session access mode.

Like all pages need session?

On large app You will probably have to write
custom code and use many session databases on many servers.

I don't believe you.

 

[3P]

I am not here to hold your hand nor did you work on the project. Those
are the facts that can't be ignored.

What are you talking about? I don't understand you.

Yeah right!!!!!! And I am sure you no nothing about OOP, ASP.NET WCF Web
services and ADO.NET Entity Framework used in n-tier technology.

And You know their names only. I know more then you will ever learn.
I bet your code is ugly as hell and totally unreadable. You know nothing
about
designining, TDD, refactoring, CC, MC and other code stats. Show us one of
your
"Enterprise apps" that are "not high usage". LOL. Yeah this is enterprise
app.
No one is using it but it is enterprise. This is not the first thread
where you
talk when You have nothing clever to add.

 

[3P]

Here you go projecting again I see.

Like all pages need session?

What? Learn english idiot.

I don't believe you.

So read the books muppet. I don't know where You get your knowledge from.

 

[Mr. Arnold]

Well every thread is async.

I know page wasn't waiting for thread to finish, but still two worker
threads
were used for every page load/unload. But You said it wasn't high usage
app. That's
probably why You didn't see performance penalty.

Oh and one other thing here, the Page-Unload was calling the Page_Unload
method in the Presenter of a Model View Presenter using object injection. It
was the Presenter that was serializing the object, spawning the async
thread and calling the async ASP.NET WCF Web service.

The UI was a dumb UI with no code behind it other than to call the methods
on the Presenter and pass objects in the View Interface. As a matter of
fact, it was the Presenter that was controlling and using the session object
in the Presenter and not the Web Page. It was the Presenter that was
manipulating the Web controls in the Presenter via the View Interface for
the Web page.

 

[Mr. Arnold]

What are you talking about? I don't understand you.


And You know their names only. I know more then you will ever learn.
I bet your code is ugly as hell and totally unreadable. You know nothing
about
designining, TDD, refactoring, CC, MC and other code stats. Show us one of
your
"Enterprise apps" that are "not high usage". LOL. Yeah this is enterprise
app.
No one is using it but it is enterprise. This is not the first thread
where you
talk when You have nothing clever to add.

You clown, I have used every last bit of it MBunit, Gallio, and and Reshaper
in TDD.

You are a clown, the continues to project when you don't know jack about
anyone's situation.

And in my 38+ plus years in being in it with over 30 of them being in
programming, I have for sure forgotten more than you'll ever know. You
couldn't hold a match stick to my long and illustrious career in IT.

 

[Mr. Arnold]

<snipped>

I don't have time for a trolling clown such as yourself.

 

[3P]

You clown, I have used every last bit of it MBunit, Gallio, and and
Reshaper in TDD.

You are a clown, the continues to project when you don't know jack about
anyone's situation.

And in my 38+ plus years in being in it with over 30 of them being in
programming, I have for sure forgotten more than you'll ever know. You
couldn't hold a match stick to my long and illustrious career in IT.

Then it's time to start thinking about quitting grandpa. You start to talk
like and idiot.
Only because You are old it doesn't mean You know shit.

Like You have shown on these list You often discuss in threads altough You
don't know nothing about.

 

[Mr. Arnold]

Time out. Mr Arnold (whilst being slightly off target on this thread)
has demonstrated that he has quite considerable knowledge.

I suggest avoiding personal attacks. Its reasonable to say you don't
like a solution and to give the reasons why and to discuss the pros and
cons, but to make personal attacks often reflects badly on you. Remember
that your comments are in a public forum and will remain accessible for
many years to come. So remember that before you hit the send button.

So, be constructive. Don't be personal. If you think someone is trolling
then just ignore them.

This 3P character's career in programming is like a match stick compared
to the torch I have been carrying for over 30 years in programming.

The thing I don't like about a person like this 3P character is it tries
to project what it thinks should be happening, a sure sign of minuscule
experience.

I would hate to see that clown in a design meeting on a project working
with other developers, as it went off trying to tell everyone what it
thinks when it can hardly tie its shoe laces. I have seen its kind in
action over the years.

 

[3P]

I would hate to see that clown in a design meeting on a project working
with other developers, as it went off trying to tell everyone what it
thinks when it can hardly tie its shoe laces. I have seen its kind in
action over the years.

Time to take a pill grandpa.

 

[Mr. Arnold]

Time to take a pill grandpa.

3-Pampers you clown have someone change your Pamper, put you in your
crib and give you your bottle.

I don't have time for a play-pen escapee.

 

[TH]

I'm not recompiling but sometimes it is done automatically when files

are changed. Note that the object stored in the session has not been
changed for ages.

If you are not pre-compiling your web application, any changes to the
web.config or files in the App_Code folder will trigger ASP.NET to re-compile
the web site, which often results in a new DLL being generated - and there
doesn't seem to be any mechanism for controlling this - other than to
pre-compile.

It doesn't matter if you haven't changed your object - the
AssemblyQualifiedName in the object's type has changed and so as far as the
..NET framework is concerned the types are incompatible.

//AssemblyQualifiedName = "MyObject, App_Code.5rwy5ukp, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null"
Session["123"] = new MyObject;

//Change to App_Code or web.config triggers a recompile into a new DLL -
App_Code.1frwq8gk

//This will throw an InvalidCastException because it is expecting an
AssemblyQualifiedName of "MyObject, App_Code.1frwq8gk, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null" but the object stored in session
belongs to a different assembly (App_Code.5rwy5ukp)
MyObject o = (MyObject)Session["123"];

//This will return NULL because the cast fails
MyObject o = Session["123"] as MyObject;

The best way to handle this scenario is to use the 'as' keyword and then
re-generate the object when a null is returned.

This ONLY affects custom objects - so you should store some kind of
'customer identifier' in a standard .NET type in session e.g. a string, and
when your custom object returns as null you can use the 'customer identifier'
to re-generate the object.

I believe the only other way around this, apart from pre-compiling, is to
use Reflection to copy the object from the old assembly into an object from
the new assembly. I believe the old assembly is still accessible as the old
DLL is still sitting in Temporary ASP.NET Files - so reflection should work.