| Previous | Table of Contents | Next |
Custom application tracking of login sessions is doable, but requires a significant amount of programming effort. To provide assistance to this very commonly required scenario, the WRB provides Transaction Services. For example, in PL/SQL, developers can create a set of stored procedures, and associate them together as one transaction. One procedure is defined as the BEGIN procedure of the transaction, another as the COMMIT, and still another as the ROLLBACK. A set of procedures is defined as the boundaries of the transaction—in other words, the procedures whose work will be accepted as affecting the locked records. When the BEGIN procedure is invoked for any reason, Oracle issues a series of cookies and performs the necessary locks to create a persistent session. The locks stay until either the COMMIT or ROLLBACK procedure is invoked, or until the developer-specified timeout occurs.
The C cartridge also has transaction service support. The Java cartridge is not yet currently supported, but will be soon.
As stated earlier, the developer can create the code necessary to support persistent transactions without the Transaction Service, which theoretically makes it possible to do in any cartridge. But the Transaction Service saves a lot of development and testing effort.
Invoking a Cartridge from a Client—An Example
To appreciate how clients, the WRB, and cartridges work, it’s helpful to understand how the WAS looks at incoming Web addresses. Consider the following URL:
http://www.corbinian.com/demo/plsql/bookstore$.order_form?customer_id=1234 &first_order=T
This particular URL contains the following parts:
| URL portion | Description |
|---|---|
| http:// | This is the type of protocol being requested. Most Web browsers will also allow non-Web protocols, such as FTP (File Transfer Protocol) and others. |
| www | This is the machine for the host. |
| corbinian.com | This portion is the host name. Host names are often shown as the domain name, which is a text variable representing an IP address. An IP address is a series of 4 numbers, separated by periods, each of which ranges from 0 to 255. Each location on the network has a unique IP address. Domain names are essentially variables that are used to represent the IP address, and a master lookup table of domain names and IP addresses is distributed around the network so all systems know which physical address to connect to for any valid domain name. If the information located at one physical address needs to move to another, the master table that translates IP addresses is changed and all programmed calls to the domain name will now point to the new address—in other words, existing code that references the URL needs no modification. |
| If WAS is running at a particular Web site, this is enough of a URL to reach it. In other words, the rest of the URL is processed by the WAS. | |
| demo | Once the URL reaches this point, the WAS has received it, and refers to its internal configuration to determine what to do next. If, for example, WAS was configured to have a PL/SQL Cartridge Agent called demo, this portion of the URL would inform WAS to route this incoming request to the PL/SQL Cartridge. |
| bookstore$ | By now the WAS has identified this request as a request for a PL/SQL stored procedure. bookstore$ is the name of a stored package in the database. The particular database that this package is stored in is defined in the Database Access Descriptor (DAD), an ASCII file created by the Webserver Administrator as part of the initial configuration of the PL/SQL Cartridge. Once the WAS determined that this request was for a PL/SQL cartridge, it looked to the DAD to identify which database the request is for. Then it confirms that the package bookstore$ is a valid package in that database. |
| order_form | This is the name of the procedure in the stored package bookstore$. |
| ?customer_id | This is the first parameter being passed to the procedure. The stored packaged procedure parameter is customer_id. The first parameter in any URL is preceded by a question mark. The stored packaged procedure BOOKSTORE$.ORDER_FORM must have a corresponding CUSTOMER_ID parameter. |
| =1234 | The value being passed to the customer_id parameter (1234). |
| &first_order | The second parameter, first_order. Note that all parameters following the first are preceded by an ampersand. Again, the procedure must have this parameter. |
| T | The value being passed to the second parameter (T). Note that numbers and characters can be treated the same—no quotes. In spite of this, the stored packaged procedure parameter declaration can be specific—NUMBER, DATE, and so on. As long as the incoming data is consistent, there will be no problem. |
| Previous | Table of Contents | Next |