I think you've to go with one engine per timezone (and you could still
share engines with many sessions - as I'd presume there would many
sessions in each timezone).
Also, only Date objects (NativeDate instances in nashorn impl.) copy
timezone from "environment" (per engine object) at the time of object
creation. It does not seem anyway to avoid this.
Thanks,
-Sundar
On 28/11/16, 4:02 PM, Martin Hiller wrote:
Hi,
we are using Nashorn in a web application scenario where currently each session
has its own scripting engine. As most of the executed scripts are the same
across the different sessions, we actually want to employ a single engine for
the whole application and benefit from the common class cache and globally
cached CompiledScripts (of course every script would be executed with a
separate Global/Bindings).
However, each session potentially needs to run scripts in its own time zone,
which can afaik only be set during engine creation. So it seems to me that one
engine per session (or at least one engine per time zone) is the minimum
requirement in our scenario, isn't it?
On the other hand, if we stick to our one-engine-per-session rule, it seems
impossible to cache and reuse CompiledScripts on a global level because a
CompiledScript is tied to the engine it was created from, and this
CompiledScript will therefore always use the time zone of its corresponding
engine.
Is there an easy method or workaround to profit from global caching of compiled
scripts in a way that the time zone is retrieved at script runtime and not
fixed at engine creation time? Or do you have any other suggestion on how to
improve the depicted scenario?
Thank you for your time!
Best regards,
Martin
