Java Service Manager Thread Safety
Java Service Manager is thread-safe in the context that each JSM client program has its own thread and each object instance is only visible to this thread.
The few internal resources that have shared access have been enclosed within synchronized blocks.
The trace sequence number is a JVM global shared incrementing integer and is accessed once or twice by a thread during its lifetime. Once a thread has a unique number it does not need to access this shared data again. If tracing is off, then a thread never needs to access this synchronized resource.
All objects passed to the JSMService class are new and visible only to the current thread.
- JSMClient
- JSMTrace
- JSMContainer
- JSMStorage
- JSMResource
- JSMCommand
- JSMField
- JSMFieldList
- JSMList
- JSMResponse
- JSMException
The JSMManager class has two static methods: createTemporaryFile and clearTemporaryDirectory which create and delete files from the IFS.
The IFS is a shared resource to all threads running within the same JVM job and all other jobs running on the machine. It adds no value to synchronize these methods, because of the bottleneck it would create for threads trying to create and clear temporary files. Each thread has a unique IFS subdirectory to use for temporary storage and no resource contention will occur.
Being only visible to the current thread means that no other thread can read and write to these objects, unless the service programmer creates a new thread and passes an object reference to this new thread.
Most of the JSM classes have instant variables that are private and final, so their values cannot change after construction. All JSM classes internally use objects that have synchronized methods.
Normally only one thread is ever accessing the state of a JSM service object and these synchronized methods only add a lock and unlock overhead and do not effect the concurrency of other threads.
If another thread has access to an object reference, then these synchronized methods would then protect the shared data.
JSMClient instance variables are private and final and cannot be changed. This object is thread-safe because it is read-only and the internal state will not change.
JSMContainer instance variables are private JSMTrace, JSMStorage and JSMResource objects.
The JSMStorage object reference never changes.
The JSMTrace and JSMResource object references change when a SERVICE_LOAD command is received.
JSMTrace instance variables are private and cannot be changed and its print methods are synchronized. When the SERVICE_LOAD command is received a new JSMTrace object is created. The current JSMTrace object is closed and is no longer usable.
JSMStorage instance variable is a private and final Hashtable object. The object reference cannot be changed but the Hashtable contents can be modified by the synchronized get and put methods.
JSMResource instance variable is a private and final Hashtable object. The object reference cannot be changed but the Hashtable contents can be modified by the synchronized get and put methods.
JSMField instance variables are private and final String and DataType objects and cannot be changed.
DataTypePacked and DataTypeZoned instance variables are private and final integers and cannot be changed.
DataTypeText instance variables are private and final String, integer and byte array objects and cannot be changed.
JSMCommand instance variables are private and final and cannot be changed. This means that the internal object references will not change but you need to check the documentation on the internal behaviour of these objects. JSMCommand is just a holder object for a collection of other objects.
The JSMFieldList and JSMList objects are not thread-safe. There are no synchronized methods to protect the internal state of any instance variables. If more than one thread needs to change the contents of these objects then they will need to be externally synchronized by the programmer.
JSMResponse is not thread-safe. There are no synchronized methods to protect the internal state of an instance variables and therefore cannot be made visible to other threads of work.
JSMException instance variables are private and set at construction time and cannot be changed.