Abstract: Techniques are described for closing one or more connections with a database management system (DBMS) as part of a planned operation such as maintenance and load balancing. In an embodiment, a request is received for a planned operation of a database server of a DBMS that requires releasing and migrating database sessions. Over a database connection with the database server, the DBMS or a Client-Driver on the client system that interfaces with the DBMS, may receive request(s) from the client system. Based on the request(s), a safe point, for the database connection with the database server, at which the database connection of the client system with the database server can be closed without affecting the success of execution of next one or more command that the client system intended to request the DBMS to execute on the database server, is determined.

Abstract: Techniques are described for closing one or more connections with a database management system (DBMS) as part of a planned operation such as maintenance and load balancing. In an embodiment, a request is received for a planned operation of a database server of a DBMS that requires releasing and migrating database sessions. Over a database connection with the database server, the DBMS or a Client-Driver on the client system that interfaces with the DBMS, may receive request(s) from the client system. Based on the request(s), a safe point, for the database connection with the database server, at which the database connection of the client system with the database server can be closed without affecting the success of execution of next one or more command that the client system intended to request the DBMS to execute on the database server, is determined.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable due to a planned or unplanned recoverable error. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state, which was exposed to the client from the previous database session, on the new database session. The process masks the outage from the application.

Abstract: Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable due to a planned or unplanned recoverable error. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state, which was exposed to the client from the previous database session, on the new database session. The process masks the outage from the application.

Abstract: Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.

Abstract: Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.

Abstract: Transactional and non-transactional data for maintaining session state is described. In a session, a server instance receives, from a client, a request to execute transactional commands and non-transactional commands. The server instance sends at least one first directive executable at the client to store, in a first set of information, one or more first items representing one or more particular transactional commands that are open but not yet committed. The first set of information is maintained separately from a second set of information including one or more second items representing one or more particular non-transactional commands that have been processed. Based on committing one or more particular transactional commands, the server instance sends at least one second directive executable at the client to purge, from the first set of information, the one or more first items without purging, from the second set of information, the one or more second items.

Abstract: Methods, devices, and computer-readable media are provided for restoring state that was built up on a first session between a first server instance and a client to a second session between a second server instance and the client. Non-transactional session state that existed for the first session is preserved by repeating non-transactional commands in the second session. Transactions are executed in the second session when the transactions did not complete in the first session. The first server instance sends, to the client in the first session, information to maintain for a possible replay of commands that were sent in a request to the first server instance for execution in the first session. If the first session becomes unavailable, the maintained information may be used by the second server instance to restore the database session, masking the outage from users, applications, and clients.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable due to a planned or unplanned recoverable error. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state, which was exposed to the client from the previous database session, on the new database session. The process masks the outage from the application.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state on the new database session. The process masks the outage from the application.

Abstract: Methods, devices, and computer-readable media are provided for restoring state that was built up on a first session between a first server instance and a client to a second session between a second server instance and the client. Non-transactional session state that existed for the first session is preserved by repeating non-transactional commands in the second session. Transactions are executed in the second session when the transactions did not complete in the first session. The first server instance sends, to the client in the first session, information to maintain for a possible replay of commands that were sent in a request to the first server instance for execution in the first session. If the first session becomes unavailable, the maintained information may be used by the second server instance to restore the database session, masking the outage from users, applications, and clients.

Abstract: A process, apparatus, and computer-readable medium are provided for rebuilding a database session when a previous database session becomes unavailable and the commands previously sent for execution on the previous database session satisfy certain criteria. The process includes determining whether or not a set of commands sent by a client for execution on the previous database session is acceptable to replay based at least in part on whether or not the set of commands satisfies one or more criteria. The process further includes determining that the previous database session is unavailable. In response to determining that the previous database session is unavailable, if the set of commands is acceptable for replay, the set of commands is sent for execution on a new database session to rebuild the state on the new database session. The process masks the outage from the application.