Session State

  • Thread starter Thread starter Colin J Paterson
  • Start date Start date
C

Colin J Paterson

Is it possible to store session state for each separate user in a separate
process? We have a COM component that we want to use that is not thread safe
and has to be isolated. We would like to store this in a separate process
for each user.

Thanks for any help
 
An Integer is a binary object. I think you mean that storing a COM object in
Session is not recommended, right?

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
 
I won't even answer that...I hate threads that discuss semantics..when the
language used is sufficient to communicate the issue.

An integer is NOT a binary object, it's a base object, in my mind. Of course
I meant a COM or similiar object. Your post added no new information.

Jeff
 
I won't even answer that...I hate threads that discuss semantics..when the
language used is sufficient to communicate the issue.
Click to expand...

That's not sematics, and I tried to be nice about it by giving you an out
("I think you mean..., right?"). It has nothing to do with a COM object
being binary. It has everything to do with the threading model. I simply
used an Integer as an example. In fact, almost everything you store in
Session State is binary. When people point out my mistakes, I admit them, as
hard as it is on my flesh to do so, in order to maintain my credibility.

And BTW, you contradicted yourself by saying that you wouldn't answer that,
and then answering that.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Neither a follower
nor a lender be.
 
Kevin Spencer said:
hard as it is on my flesh to do so, in order to maintain my credibility.
Click to expand...

Bravo Kevin! I like it when people point out my mistakes, personally,
because it reminds me that there is still an infinite amount of stuff to
learn. Learning is my favorite part of living.

Ray at work
 
No new information, again. Perhaps we should start a new thread? How does
this help the OP?

You are wasting my time. You obviously understood the intent of my original
message, but chose to "one up".

Why do I get sucked into this stuff?? :-)

Jeff
 
Sure, when I'm wrong, I'll admit it right away. Except when I made myself
perfectly clear and someone wants attention by arguing in semantics.

You should not store binary objects in Session. Only base types like
integers and strings.

Jeff
 
Look

Point 1) I don't care if it is scaleable, can I do it?
Point 2) The rest of the thread is pointless.
 
Colin said:
Is it possible to store session state for each separate user in a
separate process? We have a COM component that we want to use that is
not thread safe and has to be isolated. We would like to store this
in a separate process for each user.

Thanks for any help
Click to expand...

No, you cannot lock a thread to a session.
 
I think you're answering the wrong question. The primary question was " ...
store this in a separate process
for each user", which I do not believe is possible. It implies that session
variables for each user are stored/run in different threads/processes
specific to that user. This is just not the case.

Bob Barrows
 
The question is, can I store each COM object in a separate process, ignoring
anything to do with what I should be doing. Can I do it?

We are resigning ourselves to writing a PERL daemon that will do this now I
think as IIS just won't allow us to.
 
You may be able to, but i do not believe you could tie that process to a
particular session or user.

Bob Barrows
 
Colin said:
The question is, can I store each COM object in a separate process, ignoring
anything to do with what I should be doing. Can I do it?

We are resigning ourselves to writing a PERL daemon that will do this now I
think as IIS just won't allow us to.
Click to expand...

I am assuming that you are running some ASP pages and that they will
communicate (pass data to/from) the appropriate "COM object in a
separate process" using some form of Inter-Process Communication(IPC).

Assuming the above is correct, then you can communicate with a
particular process (one representing a particular user) using TCP/IP
sockets, named pipes, DDE or file/stream I/O (there are other methods,
e.g., shared-memory configurations, but I haven't used them under Windows).

Easy way: assign unique port numbers (e.g., 127.0.0.1:8080,
127.0.0.1:8081, 127.0.0.1:8082, etc.) to each user and, on system
startup, start a separate resident TCP/IP (or easier, HTTP listener
process for each user. When a listener receives a request it
authenticates the request, processes it using the COM component and
returns a result. If the listener doesn't respond within an appropriate
time, a timeout should occur and appropriate action taken. The ASP page
could use the ServerXMLHTTP object to send a request to the appropriate
listener and fetch the response.

As an aside, note that what you describe is a "Web Service" (roughly, a
function call performed over a network) so under some circumstances you
_might_ want to look at the tools (e.g., Visual Studio, Perl SOAP
http://search.cpan.org/search?query=SOAP&mode=all ) you have available
for turning your component into a formal Web Service (although I don't
recommend that initially since it may introduce some unwelcome and
unnecessary complexity).

Good Luck,
Michael D. Kersey
 
What we are writing is a Web Service but it still has the same problems as
it is hosted under IIS. The method you describe is similar to the one we
have used in the past but it is a pain in the ass and we thought we might
revisit it under ASP.NET as the old system worked under old ASP (as a web
application). We are going to use the named pipe solution under PERL it
seems although I was hoping we could use .NET as it is much nicer
technology.
 
Back
Top