| Transactions make it possible to build robust error-tolerant applications. Typically, transactions are defined by four properties, known by the acronym ACID : -
Atomic ” Transactions are considered single atomic units of work. Either everything works or nothing works. -
Consistent ” System state is consistent from transaction to transaction. If the system was in a valid state when a transaction started, it will be in a consistent state when it completes the transaction (a new state based on the work the transaction did) or will be in the original state if the transaction failed. -
Isolated ” All transaction changes are isolated from other changes and invisible to others, until the transaction commits. -
Durable ” All transaction changes are durable and survive system shutdowns and crashes. Transaction behaviors differ slightly between WebLogic Workshop controls. Typically, when methods of a control are called, they are encapsulated within a transaction. If the method succeeds ”that is, completes without throwing an exception ”the transaction commits. If it fails, the transaction is rolled back. Transaction support is implicit in WebLogic Workshop. That is, every control method or Page Flow action is handled within the context of a transaction. TRANSACTIONS AND CONNECTION POOLS WebLogic Workshop maintains transaction state by using the cgPool connection pool. When building database or rowset controls, often you use a different connection pool. WebLogic Workshop does not support using two different connections from within the same transaction pool unless the database drivers are Transaction Authority (XA) “compliant. If you experience a connection transactional context error when attempting to execute database methods, make sure the cgPool and your connection pool are marked as XA compliant by selecting the pool in the WebLogic Server console, and use an XA-compliant driver. Note that only one non-XA connection pool ”normally, cgPool ”can exist within a single transaction. |
For the most part, you needn't be aware of transaction state except to know which controls are transactional and which are not. In general, all user -written controls and database, rowset, and portal controls are transactional. Although you could write a control that accesses inherently nontransactional resources, the control methods would still be wrapped inside a control, but would have no effect. EJB controls might be transactional, based on their associated transaction setting. Table 8.2 provides a partial list of controls and whether they are transactional. See the documentation if you're not sure whether a control supports transactions. Table 8.2. Transactional Versus Nontransactional Controls | TRANSACTIONAL CONTROLS | NONTRANSACTIONAL CONTROLS | | User developed Database and rowset EJB (depending on method settings) WebLogic Integration (JMS and Worklist) Message Broker | Web service File E-mail Service Broker RosettaNet ebXML | |
