The establishment of the object database-memory ing paradigm requires support from the intermediate layer container

The main difference between a relational database and an object database has been described in <imagine using XML and a relational database to form an object database>: External keys are directly recorded, or traverse the foreign key sub-table. Here is another important difference: how to release object Resources. For an object database, it is equivalent to a batch of serialized objects directly stored in the database. It is not the most important whether the actual storage format is stored in a relational structure, the most important thing is that the calling program reads an object into the memory, rather than the cursor ing. In this way, there must be a problem of how to clear the used object resources when using the object database; at the same time, because the object database must be language-independent, the object release must be completed by the program caller.
XML can be seen as a serialized object structure that can be exchanged between different languages and platforms. It actually has the same requirements: if we do not simply regard XML as the presentation layer style like HTML, but the form of Object Storage, there will inevitably be overload and maintenance problems after reading XML objects, to make the program efficient, it must be completed by the program container, rather than maintained by the bean. Otherwise, it is impossible to reduce the number of programs and provide software quality. The program container generates the next shared thread to empty resources for objects that are no longer in use. In fact, the J2EE Entity Bean container is such a container, except that it is in the form of OR ing and wants to reflect the complex object entity relationships in the database. The object database can simplify the ing to a single table. If it can maintain the memory object to a certain extent like J2EE, the most important thing is to clear the memory usage, to achieve better results than the Entity Bean.
The J2EE Entity bean is basically a flat object relationship, and there is no overlapping relationship between the entity beans, which makes it not easily reflected in the actual application relationship. In actual use, the object structure is closer to an inherited tree relationship. In this structure, there is no need to clear all objects by the container. In other words, you do not need to clear all objects. The parent object itself is the container of the lower-level object. You only need to clear the parent (top-level) object to achieve this purpose. For JAVA, the JVM spam processor clears class 1 without top-level calls.

For object systems that combine XML and databases, the call process for objects is: container initialization top-level object-> initialize the sub-object handle-> fully load this object when you need to call the sub-object details-> (clear the sub-object) -> you can clear top-level objects and all remaining secondary objects when you do not need to use them.
Another task of the container is to maintain the consistency between the handle record and the actual data relationship structure. In the above process, because the detailed content is stored in the database, the upper-level object only retains the lower-level handle. This is equivalent to an nonstandard record for a structured data. Starting from this point, when there is an inconsistent conflict, it must be based on the records in the relational database. The ideal method is to implement several container management interfaces for objects, and the containers are responsible for maintaining the consistency of objects. Here, the objects corresponding to the intermediate layer are actually memory ing of serialized objects in the database. Therefore, to make the object structure formed by XML + relational databases run efficiently, efficient and reasonable management containers must be available to centrally complete highly consistent and repetitive object maintenance, the upper-layer applications can focus on specific application logic.