2

Since I haven't found any documentation of IBM's com.ibm.jscript.std.ObjectObject or com.ibm.jscript.std.ArrayObject I wanted to ask if they are thread-safe and/or synchronized, i.e. if I can safely use them in a multi-thread environment without getting problems with ConcurrentModificationExceptions etc.

PS: I know I could for example replace these objects with Maps and Lists from java.util.concurrent, but this question does not aim at finding a workaround.

xpages-noob
  • 1,569
  • 1
  • 10
  • 37
  • Can you provide a short example how to access SSJS objects multi-threaded? – Sven Hasselbach Mar 04 '16 at 12:21
  • Example where a concurrent modification could cause problems: A SSJS Object containing some data is stored in the applicationScope: `applicationScope.testobj={...}`. User A opens a XPage in which an iteration over the object is performed: `for (key in applicationScope.testobj) ...`. At the same, User B opens a XPage in which the object is modified: `delete applicationScope.testobj[testkey]`. – xpages-noob Mar 04 '16 at 12:37
  • *applicationScope* is a Map and not thread-safe. Access to it should always be synchronized. But this is not an SSJS "issue", because the variables of the scope could be modified from somewhere else. – Sven Hasselbach Mar 04 '16 at 13:35
  • @SvenHasselbach: My primary question was not related to the thread-safety of the applicationScope. In the example the applicationScope itself is not modified by the users, just the ObjectObject that is stored within. So, in my opinion, it boils down to the question whether the ObjectObject is thread-safe or not. – xpages-noob Mar 04 '16 at 13:51
  • But you are modifying the applicationScope. You don't have a reference / pointer on the applicationScope to the SSJS object, the SSJS object is serialized/externalized between the accesses. When deleting an entry from your *testobj*, you first get the object from the applicationScope, modify it's value, and then store it back to the scope (this is done by the SSJS interpreter internally). The operation of UserA is running on a different copy as of UserB. Because of this, the code won't throw a *ConcurrentModificationException*, but the code is not thread-safe. – Sven Hasselbach Mar 04 '16 at 14:12
  • @SvenHasselbach: Maybe choosing `delete` as the concurrent modification in my example was a bad idea (as it seems to be rather "special"). What if User B adds a value to the ObjectObject: `applicationScope.testobj[newkey]="newvalue";`? I doubt that the SSJS interpreter internally creates a copy of an ObjectObject everytime a value is added. – xpages-noob Mar 04 '16 at 14:31
  • @SvenHasselbach: I know you are one of the XPages gods around here and I do not want to waste your time. So forget about the example, forget about SSJS, think of it in a Java way: You have 2 threads and both concurrently modify the same object (com.ibm.jscript.std.ObjectObject). Does this cause problems like ConcurrentModificationExceptions etc., or is the ObjectObject thread-safe? – xpages-noob Mar 04 '16 at 15:07
  • 1
    As JavaScript by default, the SSJS implementation (including all their objects) is not thread-safe. – Sven Hasselbach Mar 07 '16 at 11:31
  • @SvenHasselbach: Thanks for the information. – xpages-noob Mar 08 '16 at 11:53

0 Answers0