Browse Prior Art Database

Logical Spatial Locality in Content Management Systems

IP.com Disclosure Number: IPCOM000168619D
Original Publication Date: 2008-Mar-19
Included in the Prior Art Database: 2008-Mar-19
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Abstract

In distributed systems that has one centralized server, usually the remote servers are made to be too generic so as to not take advantage of some knowledge that the central server has. This is especially true for content management systems, where on the content level there are many specialized knowledge that the remote servers are unaware of. Nevertheless, we shall present our novel idea specifically through content management systems, but in general the problem shall work just as well. Content Management systems like content manager keeps track of metadata in library servers, and documents are stored in an independent Resource Manager. Under this architecture, the resource manager is not supposed to know the data model of the library server, because the two entities are independent. The assumption is that there is logical spatial locality. That is, suppose Item Type A has an attribute called Company. Document 1 and 2 both have this attribute set to Company A, whereas document 3 has it set to Company B. If document 1 is accessed frequently, then document 2 will be accessed frequently also. Because RM and LS are independent, there is no way for the RM to take advantage of logical spatial locality, which can help dramatically improve caching and migration, for example, where the best candidates need to be picked. In essence, we propose that for each retrieve/store order the RM gets we store the essential information regarding the logical representation of the documentation, as well as collect information such as count, etc. Then we will use this information to more intelligently perform caching, migration, etc.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 58% of the total text.

Page 1 of 2

Logical Spatial Locality in Content Management Systems

As a form of preferred embodiment, we will illustrate based on Content Manager. A more general sense of the invention can be applied outside of Content Manager without altering the spirit of the invention.

The way to keep track of logical spatial locality is as follows. With the NOINDEX item type, we can define the User_ID attribute to "represent the item" (functionality already available in Content Manager). In which case, a retrieve of a document from the NOINDEX item type will form the following URL as the retrieve order:

http://arctic:9081/icmrm/ICMResourceManager?order=retrieve&item-id=A1001001A05H 18B05917C80495&version=1&collection=CBR.CLLCT001&libname=ICMNLSDB&updat e-date=2005-08-18+17%3A59%3A17.650045&token=A4E6.EkRvdU6_SeAVnDGIwBc; &content-length=0&org-filename=h%3A%5Ceclient.txt& logicalSpatialLocality=NOINDEX:ICMADMIN

In the retrieve order to the resource manager above, we added a new localSpatialLocality parameter (in bold). It shows the item type the document to be retrieved belongs to, and the value of the attribute(s) that represents the item. Thus, in a new table in the RM, called RMLOCALITY, we store information into the following columns: item type name, value of the attribute that represents the item in that item type, and item id. This is just one preferred embodiment; we could have stored more than one particular attribute.

As a r esult, when picking a candidate for clearing the cache, and the cache consists of 3 documents, d...