EJB MetaData Store
Original Publication Date: 2001-Jun-16
Included in the Prior Art Database: 2003-Jun-19
AbstractDisclosed is a software design which solves some problems and improves function in an implementation of a high-end Enterprise Java Server.
EJB MetaData Store
Disclosed is a software design which solves some problems and improves function in an implementation of a high-end Enterprise Java Server.
In a conventional Enterprise Java Server the Container reads and parses the EJB deployment descriptor information in a deployed jar file when the jar file is first referenced. It then caches the deployment information within the JVM and reuses it thereafter whenever needed. This works well in a conventional EJ Server because there is a single, long-lived JVM which needs to read and parse the deployment descriptor only once.
In CICS (TM), EJB support is implemented using multiple transient JVMs, so if the conventional approach were used, the metadata from a jar file would have to be read, parsed and cached each time a new JVM instance first referred to a deployed jar file. This would introduce a significant performance overhead due to the additional I/O required to read the deployment descriptor from file and the CPU activity required to parse the deployment descriptor and build the internal deployment descriptor object, for each new instance of multiple JVMs.
The main advantage of the invention (outlined below) is that it solves the performance problem described above, but there are other incidental advantages, one of which is that it allows the beans installed in a CICS region to be made visible via the CICS SPI, which would otherwise not be possible.
The CICS solution to the potential performance problem outlined above is to implement a "MetaData Store" within core CICS. This is used to maintain a binary representation of the metadata for each bean installed in the CICS region. The metadata store is populated as each deployed jar file is installed, with the Container code reading and parsing the deployment descriptor for the jar file and building a deployment data object for each bean as for a conventional EJ Server. Then, as well as caching the metadata object within the JVM, the Container code passes it as a binary unit via the Java-to-CDURUN interface mechanism (a separate invention) to core CICS, which stores it in an in-memory "MetaData Store" under a key comprising the logical server name and the Enterprise Java Bean name. This key is then used by the Container code when it needs to obtain the cached metadata from CICS.
Hence, the metadata representing the deployment data is cached both within each JVM which has used a bean and in the CICS metadata store, from which it is reloaded as needed when a new JVM instance needs to access it for the first time. The contents of the metadata store are lost over a cold start, but...