You explicitly create a private pipe by calling the CREATE_PIPE function. The process then calls the UNPACK_MESSAGE procedure to access each of the items in the message. When SEND_MESSAGE is called, all messages that have been stacked in the local buffer are sent.Ī process that wants to receive a message calls the RECEIVE_MESSAGE function, designating the pipe name from which to receive the message. The information in this buffer is sent by calling the SEND_MESSAGE function, designating the pipe name to be used to send the message. This procedure adds the message to the session's local message buffer. The sending session builds a message using one or more calls to the PACK_MESSAGE procedure. However, once buffered information is read by one user, it is emptied from the buffer, and is not available for other readers of the same pipe. Any number of schema users can write to a public pipe, as long as they have EXECUTE permission on the DBMS_PIPE package, and they know the name of the public pipe. Writing and Reading PipesĮach public pipe works asynchronously.
The domain of a public pipe is the schema in which it was created, either explicitly or implicitly. You must deallocate explicitly-created pipes by calling the REMOVE_PIPE function. You create an explicit public pipe by calling the CREATE_PIPE function with the private flag set to FALSE. Because the pipe descriptor is stored in the SGA, there is some space usage overhead until the empty pipe is aged out of the cache. For implicit public pipes, the pipe is automatically created when it is referenced for the first time, and it disappears when it no longer contains data. You may create a public pipe either implicitly or explicitly. The operation of DBMS_PIPE is considered with regard to the following topics: Be careful using pipes when transaction control can be affected. All information in pipes is lost when the instance is shut down. Information sent through Oracle pipes is buffered in the system global area (SGA). This is the maximum time to wait attempting to send or receive a message. Security can be achieved by use of GRANT EXECUTE on the DBMS_PIPE package by creating a pipe using the private parameter in the CREATE_PIPE function and by writing cover packages that only expose particular features or pipenames to particular users or roles.ĭepending upon your security requirements, you may choose to use either Public Pipes or Private Pipes. Another session can keep reading out of the pipe and display it on the screen or write it to a file.Ĭoncentrator: This is useful for multiplexing large numbers of users over a fewer number of network connections, or improving performance by concentrating several user-transactions into one DBMS transaction.
Because this is an "after" trigger, the application would want to do a " SELECT FOR UPDATE" to make sure it read the correct data.ĭebugging: Triggers and stored procedures can send debugging information to a pipe. The application would then read the data to get the current value. If an "after-row" or "after-statement" trigger were to alert an application, then the application would treat this alert as an indication that the data probably changed. Independent transactions: The pipe can communicate to a separate session which can perform an operation in an independent transaction (such as logging an attempted security violation detected by a trigger).Īlerters (non-transactional): You can post another process without requiring the waiting process to poll. The service can be written in any of the 3GL languages that Oracle supports. The requestor can check (with or without time out) at a later time. The requestor of the service does not need to block a waiting reply. Additionally, the services are available asynchronously. This can be done effectively in a shared server process, so that several instances of the service are executing simultaneously. Pipe functionality has several potential applications:Įxternal service interface: You can communicate with user-written services that are external to the RDBMS.
0 kommentar(er)
