The subject matter discussed in the background section should not be assumed to be prior art merely as a result of its mention in the background section. Similarly, a problem mentioned in the background section or associated with the subject matter of the background section should not be assumed to have been previously recognized in the prior art. The subject matter in the background section merely represents different approaches, which in and of themselves may also correspond to embodiments of the claimed inventions.
With respect to modern database systems, the concept of atomicity represents the idea that transactions having multiple sub-parts either fully complete, or be fully rejected. Consider for example a bank transaction. A successful transaction may include (1) a withdrawal from a first account and (2) a credit to a second account. However, if a problem were to occur during the transaction, it is feasible that an account is credited without a corresponding withdrawal or alternatively, that a withdrawal occurs, without a corresponding credit. It may therefore be preferable that an entire transaction is rejected outright rather than completing partially. Thus, continuing with the example above, if both the withdrawal and the credit are not successful, then both are rejected or prevented, rather than allowing for a partially successful transaction.
Data stored within a database is said to be persistent when it is written to the database and then committed to the database, thus making the data available for later retrieval. Some data is persistent by its nature and is thus is kept persistently. Other data is transient by nature, and thus, its usefulness is fleeting, and the data is soon discarded. For example, a persistent record of a successful withdrawal and credit from the above example may be kept. However, a message or instruction to perform a particular action may be transient, and need not be retained once the message or instruction has been completed.
Using a database to store transient data such as messages and instructions dispatched by a messaging system burdens the database system with a computational load, particularly in an on-demand system responsible for a large number of varied tasks. For example, using the database system for transient data may include enqueuing a message or instruction for an action to be taken into a database, inserting a record having the transient data necessary to perform the message or instruction into the database, and then once message or instruction is completed, removing the record of transient data from the database as it is no longer needed, and dequeuing the message or instruction from the database. The database provides transactional atomicity but the computational burden on the database will increase as the number of messages and transactions increases.
A messaging system which does not utilize a database to ensure transactional atomicity either lacks transactional atomicity or must implement complex mechanisms to ensure atomicity, such as a two phase commit or distributed transaction.
It may be desirable to unload computational burden from such a database and also negate the need for messaging systems which implement complex mechanisms to ensure atomicity. The present state of the art may therefore benefit from the methods, systems, and apparatuses for supporting transactional message handling in an on-demand service environment as described herein.
USPTO Backgrounds
USPTO Backgrounds