Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: A server set may provide a document service to one or more clients, and may be configured to do so in view of various considerations such as availability, fault tolerance, flexibility, and performance. Presented herein are document service architectures that involve partitioning the document set into at least two document ranges, and configuring respective servers of the server set to host one or more agents to which are respectively assigned one or more document ranges. A request for an operation involving at least one document may be routed to a server hosting an agent managing the document ranges of the documents involved in the operation. Moreover, respective servers may retain detailed information about neighboring servers (e.g., according to a logical or physical proximity) and scant information about distant servers, thereby avoiding both the extensive information exchange of highly informed network architectures and the inefficiency of uninformed routing algorithms.

Abstract: Object-oriented application languages often provide resources to applications for accessing objects stored in the volatile application memory region, and, separately, for packaging objects for persistent storage and network transport by serialization and deserialization involving a storage format. However, this design creates discrepancies between the application language and storage format, and depends on affirmative serialization and deserialization by the application. Presented herein are techniques for providing object access to objects involving persisting the objects as documents in a document store, where such persistence occurs automatically upon object creation and updating, and where such objects are stored in a language format integral to the application language (e.g., when a JavaScript application creates an object, the objects are automatically stored as documents of the document store in a JavaScript Object Notation (JSON) format).

Abstract: Query models for document sets (such as XML documents or records in a relational database) typically involve a schema defining the structure of the documents. However, rigidly defined schemas often raise difficulties with document validation with even inconsequential structural variations. Additionally, queries developed against schema-constrained documents are often sensitive to structural details and variations that are not inconsequential to the query, resulting in inaccurate results and development complications, and that may break upon schema changes. Instead, query models for hierarchically structured documents that enable “twig” queries specifying only the structural details of document nodes that are relevant to the query (e.g., students in a student database having a sibling named “Lee” and a teacher named “Smith,” irrespective of unrelated structural details of the document).

Abstract: A common data type structure can be used to correlate access requests between applications that implement data in accordance with different types or type structures. In one implementation, a common data structure includes schemes for operations, sequences, records, and atoms (i.e., undefined). The system can then map any type structure to the schemes of the common data structure. In operation, a request for data by an application can involve identifying one or more proxies used by an application to map the data to the common data structure. The proxies map the data to the common data structure based on the shape of the data (to the extent it can be identified). The proxies then can return one or more data structures that comprise the identified mapping information. The application can then perform operations directly on the received data structures.

Abstract: A computer system displays an interactive development environment including a domain specific language (DSL) grammar input receiving area that allows the user to view and interact with DSL grammar inputs, a DSL language input receiving area that allows the user to view and interact with DSL language inputs and a parse output area that allows the user to view the current state of the DSL parser. The computer system begins stepping through each DSL language input to determine whether the DSL language inputs have created an error relative to the DSL grammar. The computer system also presents the resulting output for each DSL language input, so that as the user provides subsequent step inputs, the interactive development environment successively steps through each DSL language input and presents, at each step, the DSL grammar inputs, the DSL language inputs and the corresponding output in the parse output area.

Abstract: A database server includes logic that is operable to monitor and analyze at least events occurring within an environment of the database server and/or execution errors generated by the database server in order to detect whether a problem condition exists. The database server further includes logic that is operable to send one or more commands to a database driver of a client that is communicatively connected to the database server, the one or more commands specifying one or more actions to be taken by the database driver in response to the existence of the problem condition. The database driver includes logic that is operable to receive the one or more commands from the database server and logic that is operable to cause the one or more commands to be executed.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server, and a transaction may be opened to process a plurality of database commands. One or more commands associated with the transaction may be received from the client at the database server. Each received command has an associated command identifier. A transaction log stores the command identifier associated with each received command and indicates whether each received command has been successfully executed at the database server. After a session failure, the session is reestablished, and a command identifier for a further command is received from the client. If the command identifier associated with the further command is determined to have been stored in the transaction log, the command does not need to be executed, and the transaction may continue.

Abstract: Techniques for recovering from session failures between clients and database servers are described herein. A session may be established between a client and a first database server to handle a database query for the client. A command of the session may be received by the first database server from the client. Data requested by the command may be retrieved. Prior to responding to the command, the data is spooled to a session state stored in a repository of the first database server, and the session state is replicated to one or more additional database servers. The session state stored in the repository of the first database server enables the first database server and client to recover from a failure of the session. The replicated session state enables the additional database server(s) to reestablish the session and respond to the command, instead of the first database server, if the session fails.

Abstract: Systems and methods are described that establish and maintain a virtual session between a client and one or more database servers. A database server establishes a first session with a client wherein establishing the virtual session with the client comprises associating a virtual session identifier (ID) with the first session, generates state information in association with the first session, and stores the state information in a repository in association with the virtual session ID. After the first session fails, a same or different database server establishes a second session with the client wherein establishing the second session with the client comprises receiving the virtual session ID from the client, accesses the state information that was stored in the repository in association with the virtual session ID, and associates the state information with the second session.

Abstract: Systems and methods are described that facilitate idempotent execution of commands generated by a client for execution by a database server. Each command transmitted to the server includes a command ID generated by the client. The server attempts to execute each command and subsequently stores the command ID associated therewith in a repository along with an indication of whether the command executed successfully. When a new command is received by the server, it determines if the command ID associated therewith has already been stored in the repository. If the command ID associated with the new command has not already been stored in the repository, then the server executes the new command. If the command ID associated with the new command has already been stored in the repository and a previously-received command associated with the command ID has been executed successfully, then the server will not execute the new command.

Abstract: A common data type structure can be used to correlate access requests between applications that implement data in accordance with different types or type structures. In one implementation, a common data structure includes schemes for operations, sequences, records, and atoms (i.e., undefined). The system can then map any type structure to the schemes of the common data structure. In operation, a request for data by an application can involve identifying one or more proxies used by an application to map the data to the common data structure. The proxies map the data to the common data structure based on the shape of the data (to the extent it can be identified). The proxies then can return one or more data structures that comprise the identified mapping information. The application can then perform operations directly on the received data structures.

Abstract: A computer system displays an interactive development environment including a domain specific language (DSL) grammar input receiving area that allows the user to view and interact with DSL grammar inputs, a DSL language input receiving area that allows the user to view and interact with DSL language inputs and a parse output area that allows the user to view the current state of the DSL parser. The computer system begins stepping through each DSL language input to determine whether the DSL language inputs have created an error relative to the DSL grammar. The computer system also presents the resulting output for each DSL language input, so that as the user provides subsequent step inputs, the interactive development environment successively steps through each DSL language input and presents, at each step, the DSL grammar inputs, the DSL language inputs and the corresponding output in the parse output area.

Abstract: The present invention extends to methods, systems, and computer program products for controlling applications through inter-process communication. Applications are extended with application specific extensibility points. The application specific extensibility points permit applications that natively lack inter-process communication capabilities to participate in inter-process communication. Application specific extensibility points can provide an application with a Web based interface thereby making the functionality of the application available to other Web services and other extended applications. Accordingly, application specific extensibility points extend the functionality of applications to interoperate and be integrated with other Web services and other extended applications.

Abstract: A nominal type framework can be configured to efficiently correlate different nominal types together based on a minimum set of common type shapes or structures. In one implementation, a developer identifies a number of different nominal types of interest (source types), and identifies the minimum set of common type shapes to be accessed by an application program. The minimum set of common type shapes can then be used to create an intermediate type (target type) to which each of the other different source types can be mapped. For example, one or more proxies can be created that map shapes of the one or more source types to corresponding shapes of the created target type. The application program created by the developer, in turn, can access, operate on, or otherwise use the mapped data of each different source type through a single target type.

Abstract: A common data type structure can be used to correlate access requests between applications that implement data in accordance with different types or type structures. In one implementation, a common data structure includes schemes for operations, sequences, records, and atoms (i.e., undefined). The system can then map any type structure to the schemes of the common data structure. In operation, a request for data by an application can involve identifying one or more proxies used by an application to map the data to the common data structure. The proxies map the data to the common data structure based on the shape of the data (to the extent it can be identified). The proxies then can return one or more data structures that comprise the identified mapping information. The application can then perform operations directly on the received data structures.