public enum LocalContextScope extends Enum<LocalContextScope>
ScriptingContainer can be configured to act as a facade for multiple
(or really multiple Ruby VMs, since each
Ruby instance is a Ruby "VM"), and this enum controls
that behaviour. (this behaviour is bit like that of
ThreadLocal — it changes its behaviour
silently depending on the calling thread, an act of multiplexing.)
When you think of this multiplexing behaviour, there are two sets of states that need separate attention.
Ruby instance, which represents the whole VM, classes, global variables, etc. Then
there's attributes and so-called
variables, which are really a special scope induced by the
scripting container for better JSR-223 interop.
In this documentation, we refer to the former as "the runtime" and the latter as "the variables",
but the variables shouldn't be confused with the global variables in Ruby's semantics, which belongs
to the runtime.
|Enum Constant and Description|
Use a single runtime but variable maps are thread local.
Uses a VM-wide singleton runtime and variables.
Maintain separate runtimes and variable maps for each calling thread.
|Modifier and Type||Method and Description|
Returns the enum constant of this type with the specified name.
Returns an array containing the constants of this enum type, in the order they are declared.
clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf
public static final LocalContextScope SINGLETON
public static final LocalContextScope SINGLETHREAD
ScriptingContainerwill not do any multiplexing at all.
ScriptingContainer will get one runtime and one set of variables, and regardless of the calling
thread it'll use this same pair.
If you have multiple threads calling single
then you may need to take caution as a variable set by one thread will be visible to another thread.
If you aren't using the variables of
ScriptingContainer, this is normally what you want.
public static final LocalContextScope THREADSAFE
Known as the "apartment thread model", this mode makes
creates a runtime and a variable map separately for each calling thread. Therefore, despite
the fact that multiple threads call on the same object, they are completely isolated from each other.
(the flip side of the coin is that no ruby objects can be shared between threads as they belong
to different "ruby VM".)
public static final LocalContextScope CONCURRENT
In this mode, there'll be a single runtime dedicated for each
but a separate map of variables are created for each calling thread through
In a situation where you have multiple threads calling one
ScriptingContainer, this means
ruby code will see multiple threads calling them, and therefore they need to be thread safe.
But because variables are thread local, if your program does something like (1) set a few variables,
(2) evaluate a script that refers to those variables, then you won't have to worry about values from
multiple threads mixing with each other.
public static LocalContextScope values()
for (LocalContextScope c : LocalContextScope.values()) System.out.println(c);
public static LocalContextScope valueOf(String name)
Copyright © 2001–2015 JRuby. All rights reserved.