[Armedbear-devel] How to get a fresh session or instance

[Alessio Stalla]

On Wed, Dec 10, 2014 at 10:37 PM, Robert Dodier <robert.dodier at gmail.com>
wrote:

> On 2014-12-10, Alessio Stalla <alessiostalla at gmail.com> wrote:
>
> > On Wed, Dec 10, 2014 at 7:02 PM, Robert Dodier <robert.dodier at gmail.com>
>
> >> Well, I am loading ABCL and then Maxima into a Jetty servlet.
> >> The servlet class exposes a few methods which call Maxima functions
> >> to provide some services to Flex clients; BlazeDS is the glue.
> >> I'd like to figure out a way to ensure that different browser
> >> sessions don't step on each others toes. Maxima itself doesn't
> >> have any way to do that.
>
> > Define "step on each other's toes".
>
> Well, Maxima has a lot of global state (options, variables with values,
> user-defined functions, etc etc). Ideally from one session you wouldn't
> have any visibility into another sessions global state.
>

Ok, I was thinking - if the API surface exposed to the web is small, and
you don't have the entire Maxima language at your disposal but just a few
functions, it may make more sense to just isolate those functions (e.g. by
rebinding all the global variables they access).


>  > Would simply loading Maxima in different Lisp packages work and be
> enough for you?
>
> Not sure what you mean. Can you clarify?
>

I mean, if shared state is only in the form of variables inside Maxima (not
global Lisp stuff like variables in the common-lisp package, the MOP etc.),
then

(defpackage :maxima ...)
(load-everything-maxima)
(rename-package :maxima :maxima-session-1234)

would give you a new Maxima instance in the same Lisp image. You would have
to manually (delete-package :maxima-session-1234) after use and everything
would have to be designed so as no references to symbols in
:maxima-session-1234 leak outside it. So there are a few strong assumptions
here that might not hold for Maxima, but if they do, the solution is
relatively trivial.


>
> > In general, one ABCL instance per HTTP session doesn't seem a very smart
> > thing to do.
>
> It would be enough to make one copy of the static data in ABCL classes
> per session ... I don't suppose that's possible, except maybe by some
> heavy-duty JVM hacking.
>

It might be possible, but I don't think it would buy you much. Unless
there's some Oracle internal API I don't know of, copying stuff in the JVM
is entirely a user-space thing - you'd have to walk the object graph
recursively and copy stuff yourself, with a lot of special casing to boot.
What little you might save in performance you'd pay tenfold in headaches.
Better to invest in pooling ClassLoaders. But actually, I would go with
multiple JVMs. You'll definitely waste more resources, but you'll be sure
to be safe from unexpected issues.



>
> best
>
> Robert Dodier
>
>
> _______________________________________________
> Armedbear-devel mailing list
> Armedbear-devel at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20141210/779db028/attachment.html>
-------------- next part --------------
_______________________________________________
Armedbear-devel mailing list
Armedbear-devel at common-lisp.net
http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel