dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]DGEE/CSLIB Question about webservices lifetime


From: Chris Smith
Subject: Re: [DotGNU]DGEE/CSLIB Question about webservices lifetime
Date: Thu, 31 Jul 2003 22:40:17 +0100
User-agent: KMail/1.4.3

On Thursday 31 July 2003 14:32, James Michael DuPont wrote:
> Nicolai,
>
> I understand that sessions are not implemented,
> but what about the idea of just keeping the server side object active
> between requests? I dont care about scalability right now, just about
> being about to save data for 10 minutes. There must be a trick to keep
> DGEE from killing my session. I need to look into the source code.

You can't stop the dgee from killing your 'session'. As far as you are 
concerned, as soon as the webservice has finished executing and returned the 
response, it will be removed from memory (this isn't completely true - but 
you have no control and no say over when it _is_ removed from memory).
In fact, you have no control over which instance of the VM executes your 
requests, so you'll never have a consistent state anyway.

However (as you know) there exists both application state and session state in 
the world of dotgnu/.net. Application state is basically what you're are 
talking about here - effectively static 'data' that hangs about at the server 
and visible to your application.

This is not very far off from being complete.  Mtmoore has done shed loads of 
work towards application state handling (from which will be derived session 
state) - what we're lacking is sensible serialisation support ( in the 
traditional .net object serialisation sense) - You were looking into this 
weren't you Mike?

I've sorted the 'between calls' storage, all that we need to do is tie the 
webservice handling to the backend with some serialisation... for now we 
could uses npg's xmlrpc serialiser for the job, if you don't mind some 
limitations on what you can store (ie structs instead of objects).  When 
portable.net serislisation is a bit more advanced, then we will use that - 
but there is no reason to not proceed with the functionality we have as it 
will work.


And as far as your interest in the session ID - I don't think .net makes it 
visible to you, at least I've not come across any examples where a webservice 
or client explicity reads the sessionID - it's all handled behind the scenes 
of client and server.
We need to do the same, but I propose making the session ID visible through 
some global variable as I find that this is often very very useful.


If anyone is up for lending a hand with the state handling, I could definately 
do with the help - and I'm sure mtmoore would appreciate it too :o)

Cheers dotgnu'ers
Chris


reply via email to

[Prev in Thread] Current Thread [Next in Thread]