Here is my issue. I'm running Araneida on SBCL/Linux. When a user is
connected, I need to maintain a couple of globals, if possible,
attached to that user session. Almost all of the logic is implemented
with ajax, making cl-ajax calls to the server.
I'd rather not refactor every single ajax call to add a user session
id, but I will if I have to. Is that the best way? Is there a way to
just spin off a new thread for each connection? Are cookies a better
way?
"Jonathon McKitrick" <···········@bigfoot.com> writes:
> Here is my issue. I'm running Araneida on SBCL/Linux. When a user is
> connected, I need to maintain a couple of globals, if possible,
> attached to that user session. Almost all of the logic is implemented
> with ajax, making cl-ajax calls to the server.
>
> I'd rather not refactor every single ajax call to add a user session
> id, but I will if I have to. Is that the best way? Is there a way to
> just spin off a new thread for each connection? Are cookies a better
> way?
You might have to. A separate thread per connection won't work, because
web browsers will often connect multiple times in parallel to get
different parts of the page. You may be able to control the AJAX calls
to use only a single connection, though.
But unless you keep a persistent connection between client and server,
you will still need some way of associating a particular connection
request with a particular user.
I would think a global mapping table from session IDs to value
structures is what you will really need.
--
Thomas A. Russ, USC/Information Sciences Institute
> I would think a global mapping table from session IDs to value
> structures is what you will really need.
That's the direction I'm starting to investigate.
Is there any advantage to cookies versus sessions under Araneida? I've
not quite figured out exactly how the cookie handler would work, except
that it seems it works like a wedge in between getting and sending the
page, letting me access the cookie value in between. But actually
getting that value into a cl-ajax call might be the wrong way to
approach the problem.
Jonathon McKitrick wrote:
> Here is my issue. I'm running Araneida on SBCL/Linux. When a user is
> connected, I need to maintain a couple of globals, if possible,
> attached to that user session. Almost all of the logic is implemented
> with ajax, making cl-ajax calls to the server.
>
> I'd rather not refactor every single ajax call to add a user session
> id, but I will if I have to. Is that the best way? Is there a way to
I would say that the appropriate scope for binding threads in a web
service is the request. When a request comes in, grab a thread, give it
the context for that request, and let it handle it. When the request is
done, the thread is put back in the pool.
A connection is not the same thing as as session. A session is a set of
requests, which don't necessarily use the same connection. A browser
can close and re-open its TCP socket at any time. Moreover, browsing
can go through a proxy, which can close its connection (for instance by
being rebooted).
So associating sessions with connections is a very bad idea. It might
work for some tiny application that runs as a process on the user's
machine, with a browser connecting to http://127.0.0.1/. But in such a
thing you can just use global variables anyway.
> just spin off a new thread for each connection? Are cookies a better
> way?
Not really, because you have to keep requesting the cookie whenever you
need the data. A request comes in and you don't know the session.
If there is some session ID that you need in every request to every
URL, what you do is you smuggle that in the requests themselves.
Whenever you generate a page in the context of a session, you ensure
that all of the elements in that page which are played back to your
server (hyperlinks and forms!) contain the session ID. That way it is
handed to the next request, and so on. Each URL you generate has the ID
embedded. When it comes to forms, you can also embed it in the action
URL, or you can seed the value of an invisible field.