Entity Dictionary

The compound registration process uses some reference data that do not change very often. Examples of these data are Research Projects, Assays, People, and Salts. These ancillary data are usually accessed by CRS using some lookup mechanism, such as by name, site, and id. 

These data do not change very often, should not be entered as free text, and should introduce very little overhead into the overall registration process. It is recommended that they be cached in the application and refreshed periodically. This way, they can be accessed quickly from the memory rather than queried every time from the underline database. In memory data access is much faster than any input/output (I/O) operations, especially I/O that involves network traffic. As the dictionary data do not change very often, the performance benefit of accessing it from the cache overweighs the benefit of real-time up-to-date data. 

Developing Chemical Information Systems An Object-Oriented Approach Using Enterprise Java, by Fan Li Copyright 2007 John Wiley Sons, Inc. 

Assay assay = new Assay() int assayid = rs.getlnt( assay id )  

Map result = new HashMapO result.put(ASSAY LIST, assays) result.put(ASSAYID MAP, assayBylD) result. put (AS S AYNAME M AP, as s ay B yName) return result  

---

In this chapter, we present a way of caching the Entity Dictionary—the lookup data. Figure 13.1 is the class diagram of the Entity Dictionary framework. 

Figure 13.1 The class diagram of the Entity Dictionary, public class EntityDictionaryDao ...

At the beginning of the EntityDictionaryDao, it defines a series of constants the size and the name of each entity dictionary. Using these constants, the code allocates the Java Collection objects so that the sizes of these Collection objects do not need to expand at runtime, which causes extra CPU cycles to be wasted. Following the sizes are String constants names that are used to look up each entity dictionary. The class also defines SQL statements that are used to query the entity dictionary as static variables and initialize them in a static block ... 

The core of the EntityDictionaryDao is in the retrieve...() methods. Here we assume the entity dictionaries are stored in a relational database. They can also be accessed from other types of data sources, such as web service, XML, and flat files. The point is to transform them into something that can be accessed easily and quickly by CRS. Take a closer look at the retrievePersonnel() method. Like most other retrieve...() methods, retrievePersonnel() returns a Map. What is in the Map depends on what kind of lookups the clients want to use to access the personnel dictionary. In the context of CRS, the personnel data can be accessed by its entirety, the research site where the person is located, person id, person s full name, or person s username. Therefore, the Map that retrievePersonnel() returns has four Collections—an entire personnel list, a site-people map, a person id-person map, a person s full name-person map, and a username-person map. 

The code does not rerun the query for each lookup. It accesses the data only once from the data source and adds the Person object from each row to all lookups in each iteration of the while loop. This approach offers good performance for building the entity dictionary. 

EntityDictionaryManager has two responsibilities provide entity dictionaries to clients and refresh the entity dictionaries from the data source periodically. The first responsibility is accomplished by its public API—the getters. The second one is accomplished by its private refresh() and load...() methods, and a background thread that wakes up every 30 minutes. 

The class first declares a set of static variables for holding the entity dictionaries. Its private constructor and the static getlnstance() method make it a Singleton. Its load...() methods call EntityDictinaryDao to load the entity dictionaries from the data source. Let us again use personnel dictionary as an example. The code snippet of the loadPersonnel() method is as follows ... 

The above are all good until the entity dictionaries change in the data source. What if new employees are added and new projects and assays are registered What if some employees are terminated These situations require the entity dictionary cache in the EntityDictionaryManager get refreshed periodically. The following static block accomplishes this task ... 

System.out.println( Entity dictionary refresh thread interrupted... + ex.getMessage()) break ... 

The static block is executed when the class is loaded into the JVM. Look at what the static block does. It creates an anonymous inner class of type Thread—the refreshThread. Its run() method puts the thread into sleep for a period of time (30 minutes in our code example). When it wakes up, it calls the refresh() method of the EntityDictionaryManager. The static block starts the refresh thread, which means that the entity dictionary refresh is handled by an independent thread. The thread is in an indefinite while-loop that puts the thread into sleep after every entity dictionary refresh. The thread wakes up every 30 minutes and does the next entity dictionary refresh. 

The above entity dictionary module provides fast, in-memory access of most frequently accessed data for the compound registration process while keeping the in-memory cache up-to-date. In a multitiered system, controlling network traffic is critical to its speed and user experience. The above design eliminates the need of querying the database every time a piece of data is asked for, and since the system can use the cached dictionaries to display only the valid entities to the user, it also reduces human errors. 

---