MXPA99003898A - System of administration of database and method to store persistent and not persistent attributes - Google Patents

Abstract

A method and apparatus for storing non-persistent attributes separately from persistent attributes in a print management system is provided. The system server can register back-demand functions with the database of objects, which allow an attribute to be stored in a non-persistent way, even when it is obtained from the object database, if it had been stored as one of the attributes persistent The server tries to retrieve the attribute of an object database. The object database can then determine if the requested attribute has been registered as non-persistent in a separate virtual memory. If the requested attribute is registered as non-persistent, the object database invokes the back-demand function. Otherwise, if the requested attribute is not as non-persistent, the object database retrieves the information from the disk using a database application program.

Description

SYSTEM OF ADMINISTRATION OF DATABASE AND METHOD TO STORE PERSISTENT AND NON-PERSISTENT ATTRIBUTES BACKGROUND OF THE INVENTION 1. FIELD OF THE INVENTION This invention relates to the handling and storage of attributes in a print management system. In particular, this invention is directed to the separate storage of persistent and non-persistent attributes. 2- Description of the Related Art The printing management systems provide a method of controlling and accessing various printers and to manage other information related to distance. However, in current systems, the degree to which these functions can be used is limited by the fixed set of predefined attributes of the system. Attributes are collections of data that describe the entities that make up the print management system. In other words, attributes define or characterize abstract objects and entities in print management systems. For example, REF .: 30046 document attributes, such as canvas, margin, orientation, etc., that describe how the printed material should appear. The attributes of the printer, such as viewed media, alphanumeric characters in these, etc., describe the available resources or features of the printer. Other attributes of the printer can describe the different characteristics that users can use to produce high-quality documents, or they can describe the status or configuration information, such as the status or location of the printer. In addition to these attributes, there is a set of attributes to facilitate the functions of operator and administration to the end user. In summary, attributes are a set of data that describe the objects of the print management system. There are three basic elements for an attribute: object identifier (OID), a syntax and a value. An OID is a unique global identifier of an attribute which is encoded so that it can be understood by all printing systems. The OIDs are assigned following a tree format, so that each vendor or standard organization of printers is designated as a branch of this tree. Then each organization can be assigned unique OID by means of an additional branch.

For example, the "work-owner" OID is 1.0.10175.1.3.1.3 in the ISO 10175 standard for Document Printing Applications (DPA). If the server receives the "work-owner" attribute, the server can store the attribute 5 or send this information to a counting log after completing a print job using the OID, for example. Then a counting program written by a third party vendor can easily interpret the information in the chronological log lü count through the OID. The syntax of an attribute is the format in which the value of the attribute is represented. For example, the syntax of the "work-owner" attribute is "Chained Distinguished Name", which is an example of Ib coded computer language or printing system comprises. The value of an attribute is the case of the attribute. For example, the value of "work-owner" could be "John Jones", that is, the name of the person to whom the print job belongs. Figure 1 is a diagram of a print management system 100 showing the interaction between the client 1J0, the server 110 and the output device 140. The output device 140 is, for example, a printer b. The client 130 is the interface between the user and the print management system. The server 110 takes the print request from multiple clients 130, schedules the print jobs based on the print requests and then sends the print jobs 5 to the output device 140. For example, when a user presents a print job selecting documents, the printer and other attributes, the client 130 places this data together and sends them to the server 110. The server 110 then reads the data and stores the data of the document in a print data memory and creates an abstract entity, a work object, which contains the attributes specified in the data packet of the client 130 and stores these in a database of objects 120. When an output device 140 is Ib ready to print a new job, the server 110 retrieves the data from the document of the print data memory and sends the data of the document to the output device 140. The server 110 also retrieves the attributes of the work object from the base of data of objects 120, and On the basis of these attributes, it sends print controls to the output device 140. The processing of the attributes in a printer management system is described, for example, in US Patent Application No. 08 / 976,180, "INTERFACE 2b FILTRATION FOR ADMINISTERING PRINTING SYSTEM INFORMATION ", filed on November 21, 1997, and US Patent Application No. 08 / 966,406," DYNAMIC EXTENSION OF PRINTING CAPACITIES ", filed on November 7, 1997, the subject matter The object of which is incorporated herein by reference: Many object-based programs store attributes persistently (that is, stored in a resident memory continuously read and updated), so that this information can be maintained during the remicio of the system. As shown in Figure 2, a database of object 120 is often used to achieve this persistence. However, there are many attributes that do not need to be stored persistently, such as Ib those that are readjusted with the service or are calculated dynamically. Storing those non-persistent attributes in the object database increases the number of input and output transactions required, increases the use of disk space, and slows down the operation of the system.

BRIEF DESCRIPTION OF THE INVENTION This invention provides a method and apparatus for storing non-persistent attributes separately to 2b from persistent attributes in a print management system. The system server can register back-demand functions with the database of objects, which allow an attribute to be stored in a non-persistent way, obtaining in addition to the object database b as if they had been stored as one of the persistent attributes. The server tries to retrieve the attribute of an object database. The object database can then determine whether the requested attribute has been registered as non-persistent in a separate virtual memory. If the attribute If the requested database is registered as non-persistent, the object database invokes the back-demand function. Otherwise, if the requested attribute is not registered as non-persistent, the object database retrieves the information from the disk using a database application program. These and other features and advantages of this invention are described or are apparent from the following detailed description of the preferred embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS The invention is described in detail with reference to the following drawings, in which similar numbers represent similar elements and wherein: Figure 1 is a conventional flow chart of the document and the attribute data in a system of 2b printing administration; Figure 2 is a conventional flow diagram of the data, of attributes between an object database and a server system; Figure 3 is a diagram showing the flow of b the attribute data using a virtual memory; Figure 4 is a diagram of virtual memory; and Figure b is a flow diagram of the object database implementation.

DETAILED DESCRIPTION OF THE PREFERRED MODALITIES The following modalities illustrate the use of non-persistent attribute storage in printing systems. However, the use of the invention in printing systems is only an exemplary illustration. He Ib separate storage of non-persistent attributes can be applied to any object-oriented system. Figure 3 is a diagram of a server system 200 showing the interaction between the server 110, the object database system 120 and the virtual memory 330. The database system object 120 includes any devices of memory, data processors, database management programs (such as Oracle, etc.) known, etc. The database system of objects 12U reads and writes attributes to or from disk b when required by server 110. The database system of objects 120 performs this function for both persistent and non-persistent attributes. However, non-persistent attributes are stored in virtual memory 330. b Although the object database system 120 and virtual memory 330 are shown as separate units from the server 110, the object database system 120 and the virtual memory 330 may be included as internal or external memories of the server 110. When they are external, the database system 120 and the virtual memory 330 can be centralized even if the server system 200 is distributed. However, to facilitate the discussion, if the object database system 120 and the virtual memory 330 are internal or external to the server, or Ib are distributed or centralized, can be referred to here after as the object database system 120 and virtual memory 330. If the request for an attribute is made, the object database system 120 searches for the attribute requested in the virtual memory 330. If the attribute is found in the virtual memory 330, the system of the object database 120 calls the particular back-demand function. As shown in Figure 4, virtual memory 2b 330 can include two types of non-persistent attributes, reset attributes 410 and calculated attributes 420. Reset attributes 410 are attributes that are reset during system reboot. For example, an attribute of * state "is an attribute that changes regularly during the course of system operation, even during system reboot, the value is reset to an initial value.A calculated attribute can be calculated or derived from others attributes during the system restart and / or the processing time An example of a calculated attribute 420 is the position of a print job in the print queue The calculated attributes 420 may also be of the type that are not stored in the virtual memory 320 but can be calculated using the appropriate back-order function, for example, the value of the position of the print job in the print queue is an attribute that changes frequently, since more jobs in the print queue are, processed and fewer jobs in the print queue are promoted or change priority.In the queue that contains a large number of jobs, 1,000 for example, it would be difficult for the object database 120 to update in transaction mode the position attribute of the tail of each job each time a job is removed from the queue for processing or each time a job changes position in a queue due to to a priority promotion or modification. For example, when a print job is completed, the print job currently in position 10 will move to position 9, etc. If another person creates a print job with higher priority and places the previous job 5 in position 9 in the print queue, the print job in position 9 would be placed again in position 10. In this way, the positions of the Print job can change several times in a minute. However, because a job position in the queue, remixing the system can be calculated from its priority and presentation time, there is no need to maintain the position attribute in the queue persistently. These non-persistent attributes can be stored in a virtual memory 330. The The object database system 120 can then access the virtual memory 330 so that the position attribute of the print job can be easily calculated from its priority and presentation time. In this way, the position of the print queue can be Provided to an applicant without the need to maintain the attribute persistently and overload the database system of objects 120. To provide this capability of non-persistent attributes to the object implementations, the system of b the object database 120 should allow the registration of an attribute as non-persistent. The implementation of the object that registers an attribute as non-persistent provides a set of back-demand functions that can be used by the database system of 5 objects 120. These back-demand functions are a FunctionFactor, FunctionGet, FunctionRepeat, FunctionPresent and Suppress function. The SetFunction is called when the value of the attribute is fixed. The implementation of this function should store the value in virtual memory. The value in the virtual memory must maintain the value of the attribute according to the case of the object. The previous value of the attribute must also be maintained, in case there is a problem when the transaction is made. If the attribute is of the type Ib should never be fixed, instead of always being calculated, as in the case with the position attribute in the queue, the implementation of this function can simply be omitted. Since the value of the position in the print queue is never fixed, it is calculated when the FunctionGet. The GetObject is called when the value of the attribute is retrieved. The implementation of this function is, either, through the access of the value stored in the virtual memory for the case of the particular object or calculates the value 2b on the flight, as appropriate.

The Repeat Function is called if the transaction encounters a problem after the SetFunction has been called by the attribute. The implementation of this function resets the previous value as the current value, nullifying therefore the call of the preceding FunctionFi ar. If the present function is called to determine if the attribute has a value for the case of the specified object. The print management system allows the attributes of the object not to have values. This function simply returns' True 'if the attribute has a value in the virtual memory for the case of the specified object, or * False' if the object does not have a value. The functionSuppmir is called to remove the value Ib of the attribute for the case of an object in virtual memory. The database system of objects 120, gives the illusion that all attributes are stored persistently, because all attributes are stored and retrieved using the same methods. Without However, the implementation of the database system 120 provides differentiation between persistent and non-persistent attributes based on the record of object implementations. The five simple functions above are all required to alleviate a tremendous 2b number of unnecessary disk inputs and outputs.

Figure 5 is a flow diagram of the object database system implementation 120. Starting at step S51Ü, the control continues to step Sb20, wherein the database system of b objects 120 receives a request to obtain or set an attribute. Next, in step S530, the system of object database 120, determines whether the requested attribute is registered as non-persistent. If the requested attribute is not persistent, the control continues until step SbbO. Otherwise, the control proceeds to step Sb40. In step SbbO, the object database system 120 invokes the obtain or fix function. Then, the control then advances to step Sb6ü and ends. Ib If the system of object database 120 determines that the requested attribute is not registered as non-persistent in step Sb3ü, the input and output (I / O) functions are performed in step S540. Then the control then proceeds to step S560 and ends. As shown in Figure 5, as well as in the example set forth above, the implementation of non-persistent attributes of a separate virtual memory is preferably performed on a general purpose, scheduled computer. However, the impiementacion of the non-persistent attributes can also be done in a computer for special purposes, a programmed microprocessor or microcontroller and elements of peripheral integrated circuits, and an ASIC circuit or other integrated circuit, a wired electronic or logical circuit. , such as a circuit of discrete elements, a programmable logic device, such as PLD, PLA, FGPA or PAL or the like. In general, any device in which a finite state machine capable of implementing the flow chart shown in Figure 5 in the illustrated example 0 above can be used to effect the implementation of non-persistent attributes. Although this invention has been described with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, the foregoing embodiments of the invention as set forth herein, are intended to be illustrative, not limiting. Various changes can be made without departing from the spirit and scope of the invention as defined in the following claims. It is noted that in relation to this date, the best method known by the applicant to carry out the aforementioned invention, is that which is clear from the present description of the invention.

Claims (14)

2. Having described the invention as above, the content of the following claims is claimed as property: 1. A database management system for storing persistent and non-persistent attributes, characterized in that it comprises: a database system that stores the attributes persistent a virtual memory that stores non-persistent attributes, where the database system determines if the attribute is stored in the virtual memory if an attribute is requested by an element of the database administration system. 2. The database administration system according to claim 1, characterized in that if the database system determines that the attribute is stored in the virtual memory, the database system calls the non-persistent attributes using a back-demand function, and where, if the database system determines that the attribute is not stored in the virtual memory, the system of the database makes the request of the system.
3. 3. The database management system according to claim 2, characterized in that the back-demand function includes one of a HoldFunction, a HoldFunction, a RepeatFunction, a PresentFunction and a SuppressFunction.
4. 4. The database administration system according to claim 1, characterized in that b the database system includes a database and a processor.
5. 5. The database management system according to claim 1, characterized in that the non-persistent attributes include calculated attributes.
6. 6. The database administration system according to claim 1, characterized in that the non-persistent attributes include attributes that are reset upon restarting the system.
7. 7. A database management system b for storing persistent and non-persistent attributes, characterized in that it comprises: storage means for storing persistent attributes; non-persistent storage media for 0 storing non-persistent attributes, wherein the storage means determines whether the attribute is stored on the non-persistent storage media if an attribute is requested by an element of the database administration system.
8. 8. The database administration system according to claim 7, characterized in that if the storage means determines that the attribute is stored in the non-persistent storage means, the storage means call the non-persistent attributes using a function of retro-demand, and where, if the storage means determine that the attribute is not stored in the non-persistent storage means, the storage means effect the system request.
9. 9. The database management system according to claim 8, characterized in that the back-demand function includes one of a Hold Function, a Hold Function, a Repeat Function, a Present Feature b and a Func: onSuppmir.
10. 10. The database management system according to claim 7, characterized in that the non-persistent attributes include calculated attributes.
11. 11. The database management system 0 according to claim /, characterized in that the non-persistent attributes include attributes that are readjusted when the system is re-addressed. The database management system according to claim 7, characterized in that the storage means includes a database and a processor. 13. A method for storing persistent and non-persistent attributes, characterized in that b comprises: storing persistent attributes in a database system; store non-persistent attributes in a virtual memory; 10 receiving a request from the database administration system of a stored attribute; and determine if the attribute is stored in virtual memory. 14. The method according to claim Ib 13, characterized in that if the determination step determines that the attribute is stored in the virtual memory, the method further comprises calling the non-persistent attributes using a back-demand function, and wherein, if the determination step determines that the attribute 20 is not stored in the virtual memory, the method also comprises carrying out the request of the system. Ib. The method according to claim 14, characterized in that the back-demand functions include one of an Obtain Function, a Set Function, a Repeat Function, a Present Function and a FunctionSuppmir. 16. The method according to claim 13, characterized in that the non-persistent attributes include calculated attributes. 1/. The method according to claim 13, characterized in that the non-persistent attributes include attributes that are readjusted when the system is re-addressed.