FieldDictionary thread safety
Hi,
My app creates and loads a single data dictionary on startup and has multiple threads using it afterwards for field list decoding. May I know if the read-methods of the data dictionary are thread-safe? In particular, my concern is these methods:
FieldDictionary.getFidDef()
FieldDictionary.expandedValueFor()
FidDef.getName()
FidDef.getOMMType()
I am using RFAJ 8.1.0 and Java 8.0
Thanks,
CM
Best Answer
Answers
-
Hello @CM Wong
Based on the RFA Java Developer Guide document section 7.9.4 Thread Safety,
All interfaces are thread-safe at the class level (static methods - if any). In addition to that, some interfaces are thread-safe at the object level. The main reason for not support the object-level
thread-safe for all methods is the performance concern.If an application developer finds out that they need access to the same object from multiple threads, then they need to
protect this object with an explicit locking mechanism.Note:
- Class-level thread-safety means that static methods (if any) can be called from multiple threads at the same time, and that if there are any class-wide resources (i.e., static data members) then access to these resources from class instances is properly synchronized.
- Object-level thread-safety means that any non-static methods implemented by the class can be called on the same object (class instance) from multiple threads at the same time.
0 -
Dear Wasin,
Thanks for your reply.
However, since the data dictionary is heavily used in the decoding of field list, if I put a lock at every of its methods, that will defeat the purpose of using multiple threads for handling of OMM messages.
I just wonder if I can call the mentioned methods from multiple threads safely since all of the methods are read-only (i.e. they won't modify the data dictionary)
Regards,
CM
0 -
I have no problem with the developer guide. But since all of the methods I call don't modify the field dictionary, I just wonder if they can be safely called from multiple threads.
Please take a look at the javadoc for HashMap. It mentions:
If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally.
In fact, if all of the threads calling a hash map don't modify the map at all, they don't need to do any locking.
This is may question for field dictionary.
Thanks,
CM
0 -
Hello @CM Wong
I have checked with the development team. You can use the following data dictionary read methods without any locking mechanism implementation on your side:
- FidDef.getName()
- FidDef.getOMMType()
However, you need to implement locking mechanism when using FieldDictionary.getFidDef() and FieldDictionary.expandedValueFor() methods in multi threads application. The reason is these methods have additional logic to return the values, so the locking mechanism is required.
Please note that FieldDictionary and FidDef classes won’t work
like HashMap as these classes have methods which has additional business
logic.0 -
0
Categories
- All Categories
- 6 AHS
- 39 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 60 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛