Oracle International Corporation

Nancy Reiko Ikeda

Carol L Colrain

Douglas N Surber

Kevin S Neel

Stefan Heinrich Roesch

Tong Zhou

Jean De Lavarene

Paul Parkinson

Michael Chiocca

Todd Jeffery Little

Lakshminarayanan Luxi Chidambaran

Vivekanandhan Raja

Julie Basu

Sreenivas Gollapudi

Srinath Krishnaswamy

Krishnan Meiyyappan

Mehul Dilip Bastawala

Chao Liang

Rohan Ankalikar

Beethoven Cheng

Ashwinder Singh Ahluwalia

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. In an embodiment, in response to the request(s), the DBMS and/or Client-Driver, while the connection is valid, provide to the client system an invalid status for a connection test request. Such a response may cause the client system to use a different database connection to connect with the DBMS. After returning the response to the client system, the DBMS and/or Client-Driver causes the database session with the DBMS to close. In an embodiment, for database sessions to be released, the DBMS identifies a safe point in a database session by a detected request boundary or where the session states are determined to be recoverable or the failover is determined to be expected to succeed. At such a safe point, all database session states are known, and failing the session over to another database instance offering the requested service can be performed safely and transparent to applications.

Safe release of database sessions for planned maintenance operations

A system and method for reducing communications overhead in a distributed transaction processing environment such as an XA environment. In accordance with an embodiment communication overhead is reduced in a transaction by deferring a transaction end communication. The deferred transaction end communication is determined from a subsequent XA transaction communication thereby reducing the number of networks calls required for each transaction and enhancing system performance.

System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction end function

A system and method for reducing communications overhead in a distributed transaction processing environment such as an XA environment. In accordance with an embodiment communication overhead is reduced in a transaction start method by deferring a transaction start communication. The deferred transaction start communication is determined from a subsequent transaction processing communication thereby reducing the number of networks calls required for each transaction and enhancing system performance.

System and method for reducing communications overhead in a distributed transactions environment by modifying implementation of the transaction start function

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.

Recovering stateful read-only database sessions

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.

Transactional and non-transactional data for maintaining session state

Some embodiments are directed to a method and apparatus for implementing an automatic failover mechanism for a resource. A client accesses a source through a first server using a first session. During the session, the client stores checksum information corresponding to data received via the session with the first server. When it is detected that the session between the first server and the client has failed, the client is automatically connected with second server that has access to the resource. The checksum information is transmitted from the client to the second server, where it is compared with checksum information calculated at the second server, so that a determination can be made as to whether the client can continue processing where it left off when connected to the second server.

Method and system for automatic failover for clients accessing a resource through a server using hybrid checksum location

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.

Masking database outages from clients and applications

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.

A computer-implemented method of streaming a plurality of messages from a source queue to at least one destination queue over a computer network. The method may include steps of generating a remote procedure call, the remote procedure being configured to encapsulate at least header data, message data for each of the plurality of messages and an end of batch token, the header data being common to each of the plurality of messages and including an identification of the at least one destination queue, the end of batch token signaling that no further message data follows; sending the generated remote procedure call over the computer network to the destination queue identified in the header data, and dequeueing at least the message data for each of the plurality of messages from the source queue and streaming the dequeued messages over the network, and successively enqueueing each streamed message data into the at least one destination queue identified by the header data until the end of batch token is received.

Methods and systems for efficient queue propagation using a single protocol-based remote procedure call to stream a batch of messages

The present invention is directed to a method and mechanism for calling on external procedure in a database system in which the external procedure contains embedded database query language statements. According to an aspect of the invention, the external procedure executes using the same database connection and transaction as the original calling entity for that external procedure.

Method and mechanism for providing external procedures to a database system

A multithreaded client application initiates multiple database operations associated with at least one transaction. The client application allocates and stores a separate runtime context for each of the database transactions. These transaction runtime contexts are also distinct from the state information, or runtime context, of the thread initiating a particular operation of the transaction. As a result, operations started by a thread that terminates may be continued, or resumed, by a subsequent thread without having to reperform previously executed operations. The duration of the transactions' runtime context is thus decoupled from the duration of the thread's runtime context. Special syntax and routines are provided for explicitly allocating a runtime context and deallocating a runtime context.

Multithreaded client application storing a separate context for each

A method and apparatus for passing runtime contexts between threads in a multithreading application is provided. A precompiler is provided which allows programmers to declare and use runtime contexts in the same manner as other conventional variable types are declared and used. Special syntax and routines are provided for explicitly allocating a runtime context and deallocating a runtime context, thus decoupling the duration of a runtime context from the duration of the thread that initiated the operations whose states are stored in the runtime context. Consequently, operations started by a thread that terminates may be continued by a subsequent thread without having to re-perform previously executed operations. Precompiler directives are provided to explicitly state which runtime contexts will be used for certain operations. A single thread can therefore use one or more runtime contexts.

Growing community of inventors

Los Altos Hills, CA, United States of America

Nancy Reiko Ikeda