Building an object database-memory mapping paradigm that requires support from a middle-tier container

Objects | data | database | middle tier

In < envision using XML and relational databases to form an object database >, the main differences between relational and object databases have been elaborated: the use of foreign keys is achieved by direct logging, or by traversing foreign-key child tables. And here, there is another important distinction to face: How to release the resources of an object. For an object database, it is equivalent to a group of serialized objects that are directly stored in the database, and it is not the most important that the actual storage form is stored in the relational structure, and it is important that the caller read the memory as an object rather than a cursor mapping; Using an object database requires the existence of a problem of how to clear out the object resources used, and since object databases are necessarily language-independent, the object release must be done only by the program caller.

       XML can be viewed as a serialized object structure that can be exchanged between different languages and platforms. It actually has the same need: If the XML is not simply seen as an HTML-like presentation layer style, but the form of object storage, then read XML objects must have a problem of overloading and maintenance, and to make the program efficient, it must be completed by the program container , and should not be maintained by the bean. Otherwise, there is no way to reduce the amount of program software quality. Creates the next common thread through the program container, emptying the object that is no longer in use, and emptying the resource. In fact, the Java EE entity Bean container is such a container, except that it is in the form of an or mapping, hoping to reflect the complex object entity relationships in the database. The object database can simplify this mapping to basically a single form, if it can maintain the memory object to a certain extent like the Java EE, the most important thing is to empty the memory footprint, you can achieve better results than the entity bean.

      java EE entity beans are basically flat object relationships, and there is no correlation between entity beans, which makes it not easy to reflect the actual application of the relationship. In real-world use, the object structure is closer to an inheritance-tree relationship. In this structure, it is not necessary for all objects to be processed by the container for its cleanup. In other words, you do not need to purge all objects, the ancestor object itself is a container for the subordinate objects, only need to clear the superior (top-level) object to achieve the goal, for Java, the JVM garbage processor will not have a top-level call to clear the entire class.
      
      for object systems that combine XML and databases, The invocation procedure for an object is: The container initializes the top-level object-> the handle of the secondary object-> fully load the object-> (clear subordinate objects) when it is necessary to invoke the detail of the subordinate object-> clears the top-level object and all remaining subordinate objects when it is not needed.

Another task of the container is to maintain the consistency of the handle record and the actual data relational structure. In the above process, because the detailed content is placed in the database, only subordinate handles are retained in the Ancestor object. This equates to an irregular record of a structured data. From this point of view, when there is an inconsistency of conflict, it must be based on the records in the relational database. The ideal way is for the object to implement a number of container-managed interfaces, and the container is responsible for the consistent maintenance of the object. Here, the object that corresponds to the middle tier is actually the memory mapping of the serialized object in the database. Therefore, to really make the object structure formed by xml+ relational database run efficiently, it is necessary to have efficient and reasonable management container, and to centralize the highly consistent repetitive object maintenance work, so that the upper application can focus on the specific application logic.

Summed up, the use of object database program paradigm, then need to have such a container: it can automatically complete the memory object cleanup work, can automatically complete with the database consistency operation. In addition, for object class programs of similar form, some automated tools can be provided to complete most of the coding, or to improve the basic consistent maintenance methods that can be inherited by the abstract class. How to implement it concretely and how high the generality will be dealt with in the sectionbase modification. At present, in the form of BMP coding, estimated after completion, you can further the common method can be abstracted.