The Transactions tab configures the component’s transactional properties. Chapter 2, “Understanding Transactions and Component Lifecycles” provides useful background for the transactional properties.
The transaction attribute determines how methods in your component participate in transactions; at the component level, the setting affects all methods. You can also set a transaction attribute for methods within a component (see “Method properties”). Values set at the method level override the component setting.
Transaction attribute in imported EJB components EJB 2.0 or 1.1 components imported from an EJB JAR file have the transaction attribute set for each method. To use the component level setting, set the transaction attribute to Default to Component for each method.
The transaction attribute can have the following values:
Not Supported (The component-level default) The component’s methods never execute as part of a transaction. If the component is activated by another component that is executing within a transaction, the new instance’s work is performed outside of the existing transaction.
Supports The component can execute in the context of an EAServer transaction, but a connection is not required in order to execute the component’s methods. If the component is instantiated directly by a base client, EAServer does not begin a transaction. If component A is instantiated by component B, and component B is executing within a transaction, component A executes in the same transaction.
Required The component always executes in a transaction. When the component is instantiated directly by a base client, a new transaction begins. If component A is activated by component B, and B is executing within a transaction, then A executes within the same transaction; if B is not executing in a transaction, then A executes in a new transaction.
Requires New Whenever the component is instantiated, a new transaction begins. If component A is activated by component B, and B is executing within a transaction, then A begins a new transaction that is unaffected by the outcome of B’s transaction; if B is not executing in a transaction, then A executes in a new transaction.
Mandatory Methods may only be invoked by a client that has an outstanding transaction.
Never The component’s methods never execute as part of a transaction, and the component may cannot be called in the context of a transaction. If a client or another component calls the component with an outstanding transaction, EAServer throws an exception.
Bean Managed For EJB session bean components only. The component can explicitly begin, commit, and rollback new, independent transactions by using the javax.transaction.UserTransaction interface. Transactions begun by the component execute independently of the client’s transaction. If the component has not begun a transaction, the component’s database work is performed independently of any EAServer transaction.
Stateless session Beans can use this attribute, but transactions begun in a method must be committed or rolled back before that method returns. Otherwise, EAServer logs an error and returns an exception to the client. Stateful session Beans can create transactions that remain open across several method calls.
OTS Style For non-EJB components only. The component can inherit a client’s transaction. If called without a transaction, the component can explicitly begin, commit, and rollback transactions by using the CORBA CosTransactions::Current interface. See Chapter 2, “Understanding Transactions and Component Lifecycles,” for more information.
Default to component (Method-level default) In the Transactions tab of the Method properties window, choose this option if the method should inherit the transaction attribute set in the component properties.
EAServer allows only one transaction per component instance A component instance may not execute in two transaction contexts. You cannot set a transaction attribute at the method level that conflicts with the component level setting. For example, you cannot set the component transaction attribute to Mandatory and a method transaction attribute to Requires New. If a method invocation would cause this rule to be violated, the server returns an exception to the client and logs the error in the server log file.
Specifies the isolation level for transactions begun by the component’s methods. This setting can be configured for the component and for individual methods (see “Method properties”). The choices are:
Read Committed
Read Uncommitted
Repeatable Read
Serialized
None (for component only)
Default to component (for methods only)
The transaction isolation level is supported for EJB 1.0 components only.
Applies to components that use a control interface in which the instance activation and deactivation correspond to transaction boundaries. In other words, the option does not apply to EJB components or any omponent that uses the control interface CtsComponents::ObjectControl (the control interface property is “Configuring a control interface”).
For EJB components and components that use the CtsComponents::ObjectControl control interface, this option is ignored; for these compnents, the Stateless option on the Instances tab determines whether the component is deactivated after every method invocation.
When Automatic demarcation/deactivation is enabled, EAServer deactivates the component instance after every method invocation. Your component need not call the completeWork or rollbackWork transaction primitives when this property is enabled. If your component is transactional, calling rollbackWork or throwing the CORBA TRANSACTION_ROLLEDBACK exception aborts the transaction. Setting any other transaction state commits the transaction.
By default, this option is enabled for new components.
If component is stateful disable Automatic demarcation/deactivation If your component maintains state across method invocations, you must disable the automatic transaction demarcation property. For example, if you read and modify class member fields in response to method invocations, you must disable this option.
When this option is enabled, client proxies for the component can transparently failover to alternate servers when a server becomes unavailable. This option cannot be enabled unless you have enabled the Automatic demarcation/deactivation option.
Automatic failover requires that your application use a cluster of servers, so that redundant servers are available to run the application’s components. The cluster must include at least one name server and clients must resolve proxy references using naming services. See Chapter 7, “Load Balancing, Failover, and Component Availability,” in the EAServer System Administration Guide for more information.
Copyright © 2005. Sybase Inc. All rights reserved. |