Hi Sundar, thank you for your quick response!
One engine per time zone is the strategy we will pursue, as there are indeed many sessions from the same time zone. I wanted to make sure there isn't a trivial obvious solution that I'm overseeing here (e.g., somehow running a CompiledScript in the context of a different engine or similar). Best regards, Martin -----Original Message----- From: nashorn-dev [mailto:nashorn-dev-boun...@openjdk.java.net] On Behalf Of Sundararajan Athijegannathan Sent: Monday, November 28, 2016 2:14 PM To: nashorn-dev@openjdk.java.net Subject: Re: Caching of CompiledScripts and related time zone issues 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
