1. Field of the Invention
The present invention generally relates to database management systems. More particularly, the present invention relates to using a plurality of subscriber types in managing a message queue of a database management system.
2. Related Art
Typically, a database management system (DBMS) implements a messaging architecture for information sharing in the DBMS. The messaging architecture includes at least one message queue that functions as a repository for messages. A message may be any type of data. Publishers are entities that publish new messages to the message queue. Subscribers are entities that consume messages from the message queue. The DBMS creates subscribers to the message queue in response to requests from clients. The clients can be database users, software programs, etc. Usually, the subscriber is interested in messages that satisfy a set of rules of the subscriber. Moreover, the creation of subscribers generally requires the creation of specific access privileges to the message queue on a per-subscriber basis to maintain security.
Further, the DBMS may allow clients to set up individual event notification registrations to notify the clients when certain DBMS-related events occur. Examples of DBMS-related events include, for example, messages being published to a particular message queue that satisfy the set of rules of a particular subscriber, instances or databases going up or down, database objects changing, and system alerts being issued.
Each event notification registration includes DBMS-related event(s) of interest and the manner of delivering the event notification to the client. For example, delivery may be made over a network to a client specified host and port, may be made by email, may be made by HTTP, or may be made by invocating a stored PL/SQL procedure. To clients, some DBMS-related events of interest are more important than others.
A method of using a plurality of subscriber types in managing a message queue of a database management system is described and provided. The method comprises creating a subscriber with a set of rules to the message queue. The subscriber is designated as one or more of the plurality of subscriber types. Moreover, an event notification registration representing a request to be notified if a message to the message queue satisfies the set of rules may be created. In response to a new message for enqueuing to the message queue, it is determined whether the new message satisfies the set of rules. If the new message satisfies the set of rules and if so determined by a triggered event notification registration, a notification is performed according to the triggered event notification registration. A requirement that a receiver of the notification dequeue the new message from the message queue depends on the subscriber type designation.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the present invention.
Reference will now be made in detail to embodiments of the present invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention.
Typically, the DBMS has one subscriber type. On the occurrence of a DBMS-related event of interest (e.g., a new message is published to a particular message queue that satisfies the set of rules of a particular subscriber), a list of event notification registrations that have been triggered is created. That is, the event notification registration represents a request to be notified if a new message to the particular message queue satisfies the set of rules of the particular subscriber. From the list, notifications are made to clients as specified in the event notification registrations. Usually, the receiver of the notification is required to connect back to the DBMS in order to access the new message and to dequeue the new message from the message queue.
Sometimes a single message queue might hold multiple kinds of messages. Some of these messages are meant for consumption by a large number of clients (e.g., database users, software programs, etc.). In effect, these are public-type messages. Other messages are regarded as highly secure and are only meant for a limited number of clients with special access privileges. In effect, these are private-type messages. For reasons of efficiency, it is advantageous to have the public-type messages and the private-type messages in a single message queue. However, for security reasons, the clients interested in the public-type messages should be allowed access to the public-type messages and denied access to the private-type messages.
In another situation, there might be a large number of clients who might be interested in certain messages of the message queue. Some of these clients may be applications running remotely. Typically, a subscriber to the message queue has to be created for each client. Moreover, after being notified of a new message of interest in the message queue, each client has to dequeue the message as the subscriber. Since the new message is meant for a large number of clients, it is necessary to create a large number of subscribers (one per dequeuing client) so that the DBMS can accurately track and decide when the new message may be removed from the message queue to ensure that the new message is available to clients interested in it. However, it may be inconvenient or impossible to create specific access privileges to a message queue on a per-subscriber basis in cases where there are a substantial number of clients requesting access to the message queue. But, if a single subscriber had been created, one client could dequeue the new message from the message queue and make the new message unavailable to other clients interested in it.
In contrast, the invention enables several subscriber types for managing a message queue of a database management system. As a result, solutions to the problems discussed above are provided. Since several subscriber types are available, a created subscriber may be designated as one or more of the subscriber types.
In an embodiment, a notification only subscriber is one of the subscriber types. If a subscriber to a message queue is designated as a notification only subscriber, a client notified of messages that satisfy the subscriber's set of rules in the message queue is not required to connect back to the DBMS in order to access the messages and to dequeue the messages from the message queue, eliminating tasks that may be inconvenient or inefficient for the client to perform. Instead, the client is able get the messages sent to it by the DBMS. Moreover, the client may simple get delivery of the notification if that is what it only wants.
Further, a public subscriber is another of the subscriber types. As discussed above, the creation of a subscriber typically requires creating specific access privileges to a message queue on a per-subscriber basis. If a subscriber is designated as a public subscriber, the subscriber does not need to be granted specific access privileges to the message queue on a per-subscriber basis. Moreover, by also designating the subscriber as a notification only subscriber, a client notified of messages that satisfy the subscriber's (which is designated as a public subscriber and as a notification only subscriber) set of rules in the message queue does not have access privileges to the message queue, ensuring security is maintained, and can only get messages that are sent to it by the DBMS. By placing responsibility on the message queue owner for creating subscribers designated as public subscribers, the subscriber is created with the proper set of rules to ensure that only appropriate messages (described above as public-type messages) are made available to subscribers designated as public subscribers.
Each subscriber 20 has a set of rules that specify messages of interest to the subscriber 20 from the messages published to the message queue 15. The rules may be based on any thing associated with a message. Data type, publisher, subject matter, and priority are examples on which the rules may be based.
In an embodiment, the subscriber types include ordinary subscriber, notification only subscriber, and public subscriber. For the ordinary subscriber, specific access privileges to the message queue 15 are created on a per-subscriber basis to maintain security. Moreover, notifications based on event notification registrations 30 triggered by messages of interest to ordinary subscribers require the receiver of the notification to dequeue the message from the message queue 15.
For the notification only subscriber, specific access privileges to the message queue 15 on a per-subscriber basis are generally not necessary. Moreover, notifications based on event notification registrations 30 triggered by messages of interest to notification only subscribers do not require the receiver of the notification to dequeue the message from the message queue 15. The receiver of the notification is able get the message sent to it by the DBMS. The message is automatically dequeued from the message queue 15 at an appropriate time by the DBMS 10.
For the public subscriber, specific access privileges to the message queue 15 on a per-subscriber basis are not created. Moreover, notifications based on event notification registrations 30 triggered by messages of interest to public subscribers do not require the receiver of the notification to dequeue the message from the message queue 15 since no specific access privileges were ever created. By also designating the subscriber as a notification only subscriber, a client notified of messages that satisfy the subscriber's (which is designated as a public subscriber and as a notification only subscriber) set of rules in the message queue does not have access privileges to the message queue, ensuring security is maintained, and can only get messages that are sent to it by the DBMS. The message is automatically dequeued from the message queue 15 at an appropriate time by the DBMS 10.
Focusing on
Continuing, at Block 230, the subscriber 20 and the subscriber type(s) 25 are stored.
At Block 240, an event notification registration 30 is created. Further, at Block 250, the event notification registration 30 is stored.
Referring to
At Block 320, a notification list of event notification registrations is created. An event notification registration represents a request to be notified if a new message to the message queue 15 satisfies the set of rules of a particular subscriber. The notification list includes event notification registrations triggered by the new message.
Further, at Block 330, an event notification registration is selected from the notification list and notification is performed as specified in the selected event notification registration.
Continuing, at Block 340, it is determined whether the event notification registration relates to a public subscriber and/or a notification only subscriber.
If the event notification registration relates to a public subscriber and/or a notification only subscriber, a notification is performed according to the event notification registration without requiring a receiver of the notification to dequeue the new message from the message queue 15, at Block 350. If needed, the new message is sent to the receiver of the notification by the DBMS 10. The new message is automatically dequeued from the message queue 15 at an appropriate time by the DBMS 10.
At Block 360, it is determined whether there is another event notification registration to select from the notification list. If there is another event notification registration to select from the notification list, selection of another event notification registration occurs at Block 330. Otherwise, selection of an event notification registration is terminated, at Block 365.
In an embodiment, the invention is configured as computer-executable instructions stored in a computer-readable medium, such as a magnetic disk, CD-ROM, an optical medium, a floppy disk, a flexible disk, a hard disk, a magnetic tape, a RAM, a ROM, a PROM, an EPROM, a flash-EPROM, or any other medium from which a computer can read.
With reference to
Computer system 400 includes an address/data bus 110 for communicating information, a central processor 101 coupled with bus 110 for processing information and instructions, a volatile memory 102 (e.g., random access memory RAM) coupled with the bus 110 for storing information and instructions for the central processor 101 and a non-volatile memory 103 (e.g., read only memory ROM) coupled with the bus 110 for storing static information and instructions for the processor 101. Exemplary computer system 400 also includes a data storage device 104 (“disk subsystem”) such as a magnetic or optical disk and disk drive coupled with the bus 110 for storing information and instructions. Data storage device 104 can include one or more removable magnetic or optical storage media (e.g., diskettes, tapes), which are computer-readable memories. Memory units of computer system 400 include volatile memory 102, non-volatile memory 103 and data storage device 104.
Exemplary computer system 400 can further include a signal input/output communication device 108 (e.g., a network interface card “NIC”) coupled to the bus 110 for interfacing with other computer systems. Also included in exemplary computer system 400 of
The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the Claims appended hereto and their equivalents.
This patent application claims priority to the co-pending provisional patent application, Ser. No. 60/799,764, entitled “DATABASE MANAGEMENT SYSTEM AND METHODS,” and with filing date May 10, 2006.
Number | Name | Date | Kind |
---|---|---|---|
5471629 | Risch | Nov 1995 | A |
5592664 | Starkey | Jan 1997 | A |
5666486 | Alfieri et al. | Sep 1997 | A |
5828882 | Hinckley | Oct 1998 | A |
5881315 | Cohen | Mar 1999 | A |
5999978 | Angal et al. | Dec 1999 | A |
6058389 | Chandra et al. | May 2000 | A |
6092102 | Wagner | Jul 2000 | A |
6182086 | Lomet et al. | Jan 2001 | B1 |
6240453 | Chang et al. | May 2001 | B1 |
6292825 | Chang et al. | Sep 2001 | B1 |
6427146 | Chu | Jul 2002 | B1 |
6438705 | Chao et al. | Aug 2002 | B1 |
6560719 | Pham et al. | May 2003 | B1 |
6757766 | Hutner et al. | Jun 2004 | B1 |
6768994 | Howard et al. | Jul 2004 | B1 |
6782541 | Cohen et al. | Aug 2004 | B1 |
6820136 | Pham et al. | Nov 2004 | B1 |
6826560 | Leymann et al. | Nov 2004 | B1 |
6829639 | Lawson et al. | Dec 2004 | B1 |
6839748 | Allavarpu et al. | Jan 2005 | B1 |
6862595 | Elko et al. | Mar 2005 | B1 |
6889231 | Souder et al. | May 2005 | B1 |
6920468 | Cousins et al. | Jul 2005 | B1 |
6931405 | El-Shimi et al. | Aug 2005 | B2 |
7039671 | Cullen | May 2006 | B2 |
7177859 | Pather et al. | Feb 2007 | B2 |
7315863 | Kambo et al. | Jan 2008 | B2 |
7509415 | Baekelmans et al. | Mar 2009 | B2 |
7584114 | Estrada et al. | Sep 2009 | B2 |
7761413 | Surlaker et al. | Jul 2010 | B2 |
7895600 | Surlaker et al. | Feb 2011 | B2 |
20010000537 | Inala et al. | Apr 2001 | A1 |
20020095399 | Devine et al. | Jul 2002 | A1 |
20020106070 | Elsey et al. | Aug 2002 | A1 |
20020116248 | Amit et al. | Aug 2002 | A1 |
20020143819 | Han et al. | Oct 2002 | A1 |
20020165998 | Hrebejk et al. | Nov 2002 | A1 |
20020184111 | Swanson | Dec 2002 | A1 |
20030004952 | Nixon et al. | Jan 2003 | A1 |
20030028495 | Pallante | Feb 2003 | A1 |
20030055768 | Anaya et al. | Mar 2003 | A1 |
20030055829 | Kambo et al. | Mar 2003 | A1 |
20030069959 | Tse | Apr 2003 | A1 |
20030208549 | El-Shimi et al. | Nov 2003 | A1 |
20040024794 | Jain et al. | Feb 2004 | A1 |
20040034664 | Jain et al. | Feb 2004 | A1 |
20040064430 | Klein et al. | Apr 2004 | A1 |
20040068481 | Seshadri et al. | Apr 2004 | A1 |
20040088401 | Tripathi et al. | May 2004 | A1 |
20040123183 | Tripathi et al. | Jun 2004 | A1 |
20040128344 | Trossen | Jul 2004 | A1 |
20040249853 | Cohen et al. | Dec 2004 | A1 |
20040254993 | Mamas | Dec 2004 | A1 |
20050003804 | Huomo et al. | Jan 2005 | A1 |
20050021622 | Cullen | Jan 2005 | A1 |
20050021976 | Trossen | Jan 2005 | A1 |
20050027742 | Eichstaedt et al. | Feb 2005 | A1 |
20050038772 | Colrain | Feb 2005 | A1 |
20050038791 | Ven | Feb 2005 | A1 |
20050038801 | Colrain et al. | Feb 2005 | A1 |
20050038831 | Souder et al. | Feb 2005 | A1 |
20050038833 | Colrain et al. | Feb 2005 | A1 |
20050038834 | Souder et al. | Feb 2005 | A1 |
20050080819 | Russell | Apr 2005 | A1 |
20050198273 | Childress et al. | Sep 2005 | A1 |
20050203908 | Lam et al. | Sep 2005 | A1 |
20060077454 | Lum et al. | Apr 2006 | A1 |
20060200501 | Holenstein et al. | Sep 2006 | A1 |
20060209868 | Callaghan | Sep 2006 | A1 |
20060235831 | Adinolfi et al. | Oct 2006 | A1 |
20070112885 | Farr | May 2007 | A1 |
20070192386 | Fries et al. | Aug 2007 | A1 |
20070214191 | Chandrasekaran | Sep 2007 | A1 |
20070240169 | Surlaker et al. | Oct 2007 | A1 |
20070240170 | Surlaker et al. | Oct 2007 | A1 |
20070250545 | Surlaker et al. | Oct 2007 | A1 |
20070266052 | Surlaker et al. | Nov 2007 | A1 |
20070266393 | Surlaker et al. | Nov 2007 | A1 |
20080098044 | Todd | Apr 2008 | A1 |
Entry |
---|
Hanson et al., “A Flexible and Recoverable Client/server Database Event Notification System,” The VLDB Journal; Springer-Verlag, 1998; pp. 12-24, vol. 7. |
Cyran, “Oracle Database, Concepts, 10g Release 1 (10.1)”, Dec. 2003; pp. 1-732. |
“Sun One Messaging and Collaboration Event Notification Service Manual,” Sun Microsystems, 2002, pp. 1-18. |
Non Final Office Action for U.S. Appl. No. 11/401,560 mailed on Jul. 6, 2009; 21 pages. |
Non Final Office Action for U.S. Appl. No. 11/401,658 mailed on Jul. 2, 2009; 18 pages. |
Final Office Action for U.S. Appl. No. 11/401,658 mailed on Nov. 3, 2009; 22 pages. |
Non-Final Office Action for U.S. Appl. No. 11/408,195 mailed on Dec. 17, 2008; 10 pages. |
Final Office Action for U.S. Appl. No. 11/408,195 mailed on Jun. 11, 2009; 17 pages. |
Advisory Action for U.S. Appl. No. 11/408,195 mailed on Oct. 8, 2009; 3 pages. |
Non-Final Office action for U.S. No. Appl. 11/471,167 mailed Aug. 11, 2009; 7 pages. |
Non-Final Office Action for U.S. Appl. No. 11/471,405 mailed on May 14, 2008; 13 pages. |
Final Office Action for U.S. Appl. No. 11/471,405 mailed on Jan. 23, 2009; 15 pages. |
Advisory Action for U.S. Appl. No. 11/471,405 mailed on Apr. 13, 2009; 3 pages. |
Non-Final Office action for U.S. Appl. No. 11/471,405 mailed on Jul. 7, 2009; 18 pages. |
Final Office Action for U.S. Appl. No. 11/401,560 mailed on Dec. 9, 2009; 27 pages. |
Advisory Action for U.S. Appl. No. 11/401,560 mailed on Feb. 23, 2010; 3 pages. |
Non-Final Office Action for U.S. Appl. 11/408,195 mailed on Jan. 20, 2010; 11 pages. |
Notice of Allowance for U.S. Appl. No. 11/471,405 mailed on Jan. 26, 2010; 8 pages. |
Final Office Action for U.S. Appl. No. 11/471,167 mailed on Dec. 15, 2009; 13 pages. |
Advisory Action for U.S. Appl. No. 11/471,167 mailed on Feb. 25, 2010; 3 pages. |
Notice of Allowance for U.S. Appl. No. 11/471,405 mailed on Apr. 20, 2010; 9 pages. |
Muthulingam et al., The Do's and Dont's of Space and Undo Management: Best Practice for Oracle Database 10g, Dec. 2004; pp. 1-34. |
Non-Final Office Action for U.S. Appl. No. 11/401,560 mailed on Jun. 4, 2010; 34 pages. |
Final Office Action for U.S. Appl. No. 11/408,195 mailed on Jun. 30, 2010; 20 pages. |
Non-Final Office Action for U.S. Appl. No. 11/471,167 mailed on Jul. 20, 2010; 13 pages. |
Advisory Action for U.S. Appl. No. 11/401,560 mailed on Mar. 4, 2011; 4 pages. |
Final Office Action for U.S. Appl. No. 11/401,560 mailed on Dec. 28, 2010; 34 pages. |
Notice of Allowance for U.S. Appl. No. 11/471,167 mailed Dec. 6, 2010, 9 pages. |
Advisory Action for U.S. Appl. No. 11/408,195 mailed on Sep. 16, 2010; 4 pages. |
Advisory Action for U.S. Appl. No. 11/401,560 mailed on Feb. 23, 2010, 4 pages. |
Office Action for U.S. Appl. No. 11/401,560 mailed on Sep. 10, 2012. |
Number | Date | Country | |
---|---|---|---|
20070276914 A1 | Nov 2007 | US |
Number | Date | Country | |
---|---|---|---|
60799754 | May 2006 | US |