Browse Prior Art Database

Logical Spatial Locality in Content Management Systems 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



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.

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...