Establish an object database-memory map, requires support for intermediate layer containers

Original load:

In One, the main differences of relational databases and object databases have been explained: the use of foreign keys is obtained by direct recording or traverse the outer key tab. And here is another important difference: how to release the resources of the object. For object databases, it is equivalent to a batch of serialized objects directly in the database, and its actual storage form is not most important in relation to relational structure, it is important that the calling program reads memory. An object instead of a cursor map; this way, using an object database must exist a problem with how to complete the resource resource; at the same time, due to the object database inevitably unrelated to the language, the object release must only be called Find.

XML can be seen as a serialized object structure that can be exchanged between different languages ​​and platforms. It actually exists: if it is not a style of Presentation Layer like HTML, Object storage, then there will be problems with heavy load and maintenance after reading XML objects, and to efficiently, it must be completed by the program container without being maintained by beans. Otherwise, reduce the quality of the program, it is not talking about it. The next common thread is generated by the program container, and the object that has no longer used is emptied, and the resource is empty. In fact, J2EE's entity bean container is such a container, but it is in the form of OR mapping, it is desirable to reflect complex object entity relationships in the database. Object databases can make this mapping to substantially a single form, and if it maintains memory objects as J2EE, the most important thing is to empty the memory, which can achieve better results than entity beans. The J2EE entity bean is basically a flat object relationship. There is no relationship between the entity bean, which makes it easy to reflect the relationship between the practical application. In the real use, the object structure is closer to one inheritance tree. In this configuration, it is not necessary to handle it from the container by the container. In other words, do not need to be cleared for all objects, the superior object itself is a container of the lower-level object, only need to clean up the upper class (top) object, for Java, the JVM spam processor will do not have a top call. A whole removal. For object systems that combine XML and databases, the calling process for the object is: Container initialization top-level object -> Initialization Secondary Object Handle -> Fully load this object when you need to call secondary objects -> (Clear Secondary objects) -> Clear all of the top objects and the remaining sub-objects when not needed.

Another task of the container is to maintain the consistency of handle records and actual data relationships. In the above flow, since the detailed content is placed in the database, only the subordinate handle is retained in the superiors. Heard, this is equivalent to a non-standardized record of a structured data. From this point, when an inconsistent conflict occurs, it must be subject to the record in the relational database. The ideal way is that the object implements a number of container management interfaces, which is responsible for maintenance of objects. Here, the object corresponding to the intermediate layer is actually a memory mapping of the serialized object in the database. Therefore, it is necessary to actually operate the object structure formed by the XML relational database, and must have an efficient and reasonable management container, and the highly consistent repetitive object maintenance work is concentrated, and the upper application can focus on specific application logic.