Embedded NREPL and session context in ThreadLocal

[Andrey Grin]

Hi,

I embeded nrepl in existing Java application. User may connect to the embedded nrepl server (in my case from Eclipse, Counterclockwise), issue some command that creates application specific session context (which e.g. holds long-running hibernate session and some other session data) and then interactively call some available APIs. Application stores session context in ThreadLocal. The commands, that are called from REPL afterwards depend on the session context. But after several seconds the next command is executed in another thread where obviously necessary session context is not initialized. In normal scenario application is executed in servlet container and initializes the thread that processes the request with necessary session context before any other logic is executed.

Maybe somebody can point me in right direction how to achieve the same with NREPL. I.e. store session data somewhere, initialize context when roundtrip begins and clear it after it ends.

Thanks

Andrey.

[Chas Emerick]

Andrey,

If your application is using ThreadLocals to maintain state, then it's
implicitly assuming that the same thread will be calling into it. As
you've discovered, that's not the case with nREPL; each evaluation is
performed on a thread from a threadpool, which can grow and shrink as
usage and the vagaries of the threadpool implementation demand.

I'm confused about how this is any different from a servlet container
though, since they generally have roughly the same architecture as
nREPL: each incoming request is handled by a different thread.
Whatever state-management or thread coordination machinery you have in
place for that environment should work equally well when interacting
with it via the REPL.

Otherwise, you could always create a new Thread that runs a dedicated
dispatch loop, into which you could add request and from which you
could retrieve results. This would ensure that the ThreadLocal-using
code always only ever sees one thread.

- Chas

> --
> You received this message because you are subscribed to the Google
> Groups "clojure-tools" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to clojure-tool...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Laurent PETIT]

I think the confusion comes from different implicit assumptions on what a session / session "context" means for different persons.