| Use MDHT Validator and EMF in multi-threaded application [message #1743814] |
Mon, 19 September 2016 21:39  |
 Haiwen Zhu
Messages: 1
Registered: September 2016 |
Junior Member |
|
|
Dear Sean Muir and MDHT Core Team,
As recommended, I've created my Eclipse account.
1. Static vs. synchronized load of MDHT Validator libraries:
Since you said earlier "once one validation is run the libraries are cached. ", and the validator will run faster and faster after a slow few at the beginning due to the library load, I have this question:
Are the validator libraries static libs? If yes, is below the best practice?
At Java class level, load the package once:
static {
ConsolPackage.eINSTANCE.eClass(); // Static package registration
}
What made you recommend below instead in your 9/7/16 email?
synchronized (LOAD_LOCK) {
ConsolPackage.eINSTANCE.eClass();
}
2. EMF Thread Safety:
In your 9/7/16 email, you shared below. We've since upgraded our AIS application to use the 08/16/2016 MDHT jars.
I spoke with Dragon at the 9/15-16 HL7 C-CDA Implementation-A-Thon on MDHT thread safety. He said EMF uses statics and therefore is not thread safe. EMF is another Eclipse Open Source project and that it's complex.
Questions:
a. Will it take huge effort for EMF to become thread safe? By replacing the statics somehow?
b. Is EMF the only reason why we shall synchronize the call to the MDHT Validator?
====== From your 9/7/16 email ======
"Below is the official response from Eclipse EMF
Is EMF thread-safe?
EMF can safely be used in multi-threaded environments; however, EMF does not, itself, ensure thread-safety in application model implementations. Data structures are unsynchronized, for performance and to avoid potential deadlock situations. The expectation is that a complete instance of the model (including resources and resource set, if present) should only be accessed by one thread at a time, and that the synchronization should be provided by the application at a higher level.
Since it is shared among multiple instances of a given application model, Ecore metadata is intended to be thread-safe for read-only access. However, there was a thread safety bug involving Ecore annotations, which is now fixed but will still affect older releases of EMF. Also, the demand initialization of SDO metadata is not thread-safe. See the following two questions for workarounds to these issues."
Thank you so much!
Haiwen Zhu
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04196 seconds
] 
Search
Help
Register
Login
Home
