- Managing Global Settings with OptionManager
- Collecting Logs Using DiagnosticManager
- Sharing Sessions Among Different Applications
- Using Single Sign-On from the VI SDK to CIM
- Downloading and Uploading Files Using HTTP Access
- Multithreading with the VI SDK
- Versioning
- Following Best Practices for Performance and Scalability
- Considering Internationalization
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Multithreading with the VI SDK
Multithreading is the norm in application development, especially GUI-related applications and server applications. In these applications, you might need several threads, each of which is assigned a specific task. When you develop your application that uses VI SDK, you need to consider using multithreading.
Overall, the AXIS generated VI SDK stubs are thread-safe, meaning you can safely issue multiple calls in different threads. For each call, a new Call object is created and not shared with other method invocations.
While using multiple threads, be aware (and careful) of the following:
-
There normally shouldn't be more than one operation currently running with one entity. Most of the invocations are fast, so you don't notice there is such a limitation. But some operations are slow. When a second call comes in before the first finishes, a TaskInProgress fault might be thrown. In that fault type, you get the first running task's MOR.
To avoid this, you can put a synchronized keyword on every operation in your Java code. This prevents the same application from issuing the second call on the same entity before the first finishes. The synchronized keyword cannot prevent other applications, either running on the same machine or not, from issuing a second call to the same managed entity on the server side. When that happens, you can do nothing about it but catch the fault and try again. The lock is essentially on the server side.
-
Pay extra attention to the PropertyCollector. The waitForUpdate() defined there is a synchronized method that reports the result as specified by the PropertyFilter objects from version to version. You get all the results for all the PropertyFilter objects. If you have multiple threads calling the waitForUpdate(), you get multiple duplicated updates. It then makes sense to have one backend thread to call the waitForUpdate().
You can implement the Publisher-Subscriber design pattern, in which the backend thread is the publisher and any other objects/threads are subscribers who can receive notifications when interested updates come. This implementation requires more effort, but it is worthwhile in big-server applications.