[Top][All Lists]
[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