|| | |||Browse by category|
Is JViews framework thread-safe?
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
Article ID: 2221
Last updated: 29 May, 2018
Posted: 21 May, 2003 by Dean J.
Updated: 29 May, 2018 by Gargani A.
Also listed in
Others in this category
Disable movements and other interactions of reservations on an IlvScheduleChart or activities on an IlvGanttChart
When using an IlvLogarithmicAxisTransformer and setting the data range on an IlvAxis, this range is not taken into account
ClassCastException occurs when deploying Web application on the Tomcat server that came with the JViews distribution
Displaying an image map for the title bar area of subgraphs in my JViews Diagrammer JSF Web application
Making a diagram's background transparent to show the HTML page's background image as the background image of the diagram
Change the behavior of the IlvDiagrammerViewBar's zoom buttons to zoom and focus on the selected graphic objects
Globally defining by code a chart property that is not specific to a series, and that is evaluated in the .css
JViews installer is failling on windows with error "Windows error 2 occured while loading the java VM"