Abstract: Implementations are described which provide for recipient-based filtering of an event that relates to a topic to which consumers are subscribed. Responsive to determining that an attribute of the event includes a set of one or more identifiers for intended recipients for the event, the event is delivered to consumers that correspond to the intended recipients. Alternatively, responsive to determining that the attribute of the event does not include a set of one or more identifiers for intended recipients for the event, the event is delivered to all of the consumers subscribed to the topic to which the event relates.

Abstract: Implementations are described for selectively publishing an event responsive to an operation on a database in a transaction. Publishing the event is delayed or not delayed respectively, responsive to determining that a value of an attribute for the event indicates that publishing the event is to be delayed, or not to be delayed, until the transaction is rolled back or committed. If publishing the event is delayed, the event is published if the transaction is committed and discarded if the transaction is rolled back. If publishing the event is not delayed, the event is published. Optionally, if the event is published, the event is published in a database or a datastore respectively, responsive to determining whether another value of another attribute for the event indicates that the event is to be published in a database or a datastore.

Abstract: Implementations store an event associated with a topic in a database to allow for the event to be transmitted in order with respect to other events associated with the topic which are stored in the database. A commit of a transaction is performed that includes inserting the event's payload in a record in a database object. After the commit, a field for the record is updated with an identifier of the commit. The identifier and identifiers of other commits of other transactions on the database indicate ordering of the commit with respect to the other commits. Another field of another record is updated based on the identifier and a last stored value such that the payloads of the event and of the other events are retrievable to be transmitted in an order based on the value of the other field and values of other fields of other records.

Abstract: Implementations are described which provide for recipient-based filtering of an event that relates to a topic to which consumers are subscribed. Responsive to determining that an attribute of the event includes a set of one or more identifiers for intended recipients for the event, the event is delivered to consumers that correspond to the intended recipients. Alternatively, responsive to determining that the attribute of the event does not include a set of one or more identifiers for intended recipients for the event, the event is delivered to all of the consumers subscribed to the topic to which the event relates.

Abstract: Techniques and structures to manage a multi-channel client-server connection is disclosed. A connection session is established between a client and in server response to receiving a call from a first browser interface element to establish the connection session. The session is shared in response to receiving a second call from a second browser interface element to establish a connection session.

Abstract: Implementations are described which provide for recipient-based filtering of an event that relates to a topic to which consumers are subscribed. Responsive to determining that an attribute of the event includes a set of one or more identifiers for intended recipients for the event, the event is delivered to consumers that correspond to the intended recipients. Alternatively, responsive to determining that the attribute of the event does not include a set of one or more identifiers for intended recipients for the event, the event is delivered to all of the consumers subscribed to the topic to which the event relates.

Abstract: Implementations are described which provide for recipient-based filtering of an event that relates to a topic to which consumers are subscribed. Responsive to determining that an attribute of the event includes a set of one or more identifiers for intended recipients for the event, the event is delivered to consumers that correspond to the intended recipients. Alternatively, responsive to determining that the attribute of the event does not include a set of one or more identifiers for intended recipients for the event, the event is delivered to all of the consumers subscribed to the topic to which the event relates.

Abstract: Implementations store an event associated with a topic in a database to allow for the event to be transmitted in order with respect to other events associated with the topic which are stored in the database. A commit of a transaction is performed that includes inserting the event's payload in a record in a database object. After the commit, a field for the record is updated with an identifier of the commit. The identifier and identifiers of other commits of other transactions on the database indicate ordering of the commit with respect to the other commits Another field of another record is updated based on the identifier and a last stored value such that the payloads of the event and of the other events are retrievable to be transmitted in an order based on the value of the other field and values of other fields of other records.

Abstract: Implementations are described for selectively publishing an event responsive to an operation on a database in a transaction. Publishing the event is delayed or not delayed respectively, responsive to determining that a value of an attribute for the event indicates that publishing the event is to be delayed, or not to be delayed, until the transaction is rolled back or committed. If publishing the event is delayed, the event is published if the transaction is committed and discarded if the transaction is rolled back. If publishing the event is not delayed, the event is published. Optionally, if the event is published, the event is published in a database or a datastore respectively, responsive to determining whether another value of another attribute for the event indicates that the event is to be published in a database or a datastore.

Abstract: Techniques and structures to manage a multi-channel client-server connection is disclosed. A connection session is established between a client and in server response to receiving a call from a first browser interface element to establish the connection session. The session is shared in response to receiving a second call from a second browser interface element to establish a connection session.

Abstract: Implementations are described which provide for recipient-based filtering of an event that relates to a topic to which consumers are subscribed. Responsive to determining that an attribute of the event includes a set of one or more identifiers for intended recipients for the event, the event is delivered to consumers that correspond to the intended recipients. Alternatively, responsive to determining that the attribute of the event does not include a set of one or more identifiers for intended recipients for the event, the event is delivered to all of the consumers subscribed to the topic to which the event relates.

Abstract: A method and apparatus for a mechanism of disaster recovery and instance refresh in an event recordation system are described. A first request for events associated with a first topic is received. A first set of events associated with the first topic are retrieved from a primary event recordation system. Each event from the first set of events includes a first commit identifier indicating the order with which each event is stored in the primary event recordation system. For each event from the first set of events a first replay identifier is determined based on the first commit identifier and a first value of a low commit identifier. The first replay identifier is exposed to event consumers for identifying the event. In response to the first request each event from the first set of events is transmitted with the replay identifier.

Abstract: A database system may determine that a database is unavailable to generate an identifier for an event or that events may not be written to the database. As a result, the database system may write the event to a low-latency, supplementary file system. The database system may determine that the database is available at a later time, and read the event from the supplementary file system, store the event in a memory component, and then delete the event from the supplementary file system. The database system may then access the database to generate an identifier for the event, write the event to the database, and then delete the event from the memory component.

Abstract: Techniques and structures to manage a multi-channel client-server connection is disclosed. A connection session is established between a client and in server response to receiving a call from a first browser interface element to establish the connection session. The session is shared in response to receiving a second call from a second browser interface element to establish a connection session.

Abstract: A method and apparatus for a mechanism of disaster recovery and instance refresh in an event recordation system are described. A first request for events associated with a first topic is received. A first set of events associated with the first topic are retrieved from a primary event recordation system. Each event from the first set of events includes a first commit identifier indicating the order with which each event is stored in the primary event recordation system. For each event from the first set of events a first replay identifier is determined based on the first commit identifier and a first value of a low commit identifier. The first replay identifier is exposed to event consumers for identifying the event. In response to the first request each event from the first set of events is transmitted with the replay identifier.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, a server of a database system accesses a metadata file indicating algorithms that can be applied to data of log files. The server generates customer-facing log files using the log file and metadata file. The customer-facing log files include new data derived from using the algorithms and the data of the log files.

Abstract: Disclosed are some examples of database systems, methods, and computer program products for processing log files. In some implementations, a server of a database system accesses a log file having a release version. The log file includes data entries identifying system events corresponding to user activity. The server generates or updates, based on the release version of the log file, a metadata file indicating approved entry types and approved data. The server also generates or updates, based on the log file and the metadata file, customer-facing log files. Each customer-facing log file is associated with a corresponding customer entity capable of being serviced by the database system. Each customer-facing log file includes a subset of the entries and a subset of the data items of at least one of the entries.

Abstract: Disclosed are methods, apparatus, systems, and computer program products for provisioning log file data. To provision the log file data, a server can parse through log files by identifying particular log entries and data fields. Customer-facing log files can be generated based on the identified log entries and data fields. A customer-facing log file has log file data specific to a particular customer, which can be a tenant of a multi-tenant database system. A security mechanism can be configured to prevent one tenant from accessing the customer-facing log file of another tenant of the multi-tenant database system.

Abstract: Disclosed are some examples of systems, methods, apparatus and computer program products for scheduling jobs to process log files. In some implementations, a scheduler can be configured to identify a final state of a previously scheduled first job as a failure in execution by one or more processors. For instance, the first job may have been defined to process a first input log file saved to a database during a first timeframe of a sequence of timeframes of a designated interval. The scheduler can detect a second input log file saved to the database. The scheduler can then define a second job to process the first input log file and the second input log file and schedule the second job in association with a second timeframe of the sequence.

Abstract: A database system captures custom information of a header section associated with a logged interaction of a user. The database system may receive a hypertext transfer protocol (http) message including the header section and determine whether the header section includes a predetermined data pattern associated with the custom information added by a second application that is different than a first application which initiated the http message. The database system may extract the custom information from the header section in response to determining that the header section includes the predetermined data pattern. The custom information and event data extracted from the logged interaction of the user may be stored on the database system as a storage element.