Data corruption with Nashorn + Handlebars and concurrent requests

[A. Sundararajan]

By "reset",  if you mean "throw all the stuff in global to get a blank 
global", then you can do this:

     ScriptContext sc  = engine.getContext();
     sc.setBindings(engine.createBindings(), ScriptContext.ENGINE_SCOPE);

This will create fresh (ECMAScript) global and makes it as ENGINE_SCOPE 
of the default context.

-Sundar

On Sunday 19 July 2015 02:37 AM, Matt Kime wrote:
> thanks, this is very helpful.
>
> one issue remains for me - is there a good way to reset the script engines
> in a development environment without restarting the whole app?
>
> --matt
>
> On Wed, Jul 15, 2015 at 1:02 PM, Sebastien Deleuze <sdeleuze at pivotal.io>
> wrote:
>
>> Hi,
>>
>> We ended up to use thread-local script engines [1] in Spring 4.2 for
>> Javascript libraries not designed for concurrency like React or Handlebars.
>> Based on my initial tests, it works pretty well. The main remaining open
>> question is about the memory consumption, since it creates one ScriptEngine
>> instance by thread.
>> If we see some blocking issues regarding this topic, we may eventually
>> experiment with a synchronized ScriptEngine pool, but I hope the
>> thread-local approach will be fine.
>>
>> Regards,
>> Sébastien Deleuze
>>
>> [1] https://jira.spring.io/browse/SPR-13034
>>
>> On Fri, Jun 5, 2015 at 5:08 PM, Matt Kime <mattk at meetup.com> wrote:
>>
>>> I'm curious if any progress has been made on isolating whatever isn't
>>> thread safe about handlebars template execution.
>>>
>>> I'm also working on using Handlebars.js inside nashorn however i'm doing a
>>> number of things different. i'm precompiling my templates using
>>> https://github.com/gruntjs/grunt-contrib-handlebars and then compile the
>>> js
>>> functions into cached bytecode.
>>>
>>> I haven't checked for threading issues yet but I'm glad i found this
>>> discussion so i know that i should.
>>>
>>