JViews framework and thread-safety

Question

Is JViews framework thread-safe?

Answer

We distinguish two cases: the first is the use of JViews in a monothread usage and the second is a pure multithread environment.

• JViews in a monothread usage
  
  JViews is designed to be used in a monothread environment mainly because it is based on AWT/Swing which is monothread and it was decided not to pay the price of synchronization when in most cases is not needed. More specifically, AWT/Swing require that all graphical operations happen in the AWT event thread (except the methods repaint() and invalidate()). Therefore, technically all JViews operations should be performed in this thread. However, JViews has been designed to reduce the need to do all the processing in the AWT thread by allowing you to use JViews from a different thread. JViews will make sure that the actions that must be performed in the AWT event thread are done in the correct thread, see the methods invokeLater and invokeAndWait in the standard class SwingUtilities.html.
  
  For more information on the threading model of Swing see Concurrency in Swing on the Oracle Java website.
  
  Therefore, we consider that JViews can be safely used from the AWT event thread or some other thread. The only exception to this rule is represented by the Charts and Gantt modules, where you must always update the data model in the AWT event thread.
  
  There are some other restrictions that apply. These restrictions mainly cover the application code which is attached to the JViews code by means of listeners and other mechanisms. When some application code is called through a listener, you need to consider the case when it is not running in the AWT event thread, so if the listener does some drawing operations you need to make sure that these operations happen in the AWT event thread. If the application code that is attached to the listeners does not handle this properly, then the application must ensure that the JViews code that calls these listeners is called in the AWT event thread.
  
  This design has the following implications:
  • The main implication is that the drawing operations that are not executed in the AWT event thread may not be executed immediately. For example, a progress bar that has to be updated as the operation happens. If the progress bar is not running in the AWT event thread, it will be updated later. JViews does not try to update the scrollbar immediately using the SwingUtilites.invokeAndWait method because it can cause a deadlock under some circumstances, and it is not possible for the JViews library to know if a deadlock will occur. If you are using a progress bar, or some other drawing that you want to update immediately, you must either handle the drawing yourself or execute the JViews method in the AWT event thread.
  • The second implication of this design is that multithreaded access to user code or the JViews libraries must be avoided. If some code is executed in the AWT event thread through the mechanisms described above, it is possible for the user code to access some objects that are in use in the main thread. If this is the case, then the user code must synchronize the access to these objects to prevent any problems.
• JViews in a multithread environment
  
  JViews has not been designed to be called safely from multiple threads, because the trade-off between the technical difficulty and the unnecessary overhead for the applications that do not support multithreading does not warrant this feature. Therefore, if an application wants to call JViews simultaneously from multiple threads, it must synchronize the calls. Obvious candidates for synchronization with JViews would be IlvManager, IlvManagerView, and so on.
  
  The JViews libraries do have some internal synchronization, but only for the cases where the synchronization could not be done correctly in the user code.The one exception to this rule is represented by the servlets that are provided with the JViews library and that are meant to run with a multithreaded servlet container. By default, servlets can be accessed concurrently by the servlet container, and so they must be thread-safe. For a simple discussion on the threading issues of servlets see this tutorial on Oracle's web site.
  
  In the case of servlets, the JViews library will synchronize the "lock" object provided by the servlet as well as the IlvManagerView, whilst the image is being generated. For more information on the "lock" object please refer to the class ilog.views.servlet.IlvManagerServlet.