Class: com.sybase.djc.ant.TransactionProperty (Transaction Property) EAServer 6.3 Help
Description Configures component-managed or container-managed transactions.
Configuration Example: 
<setProperties component="ejb.components.example.MyCompRemote">
  <transaction type="Required" retry="true"/>
  ...
</setProperties>
Nested Properties batch, entityIsolationLevel, method, prefetch, readOnly, retry, retryCount, retryDelay, sqlIsolationLevel, type

Property: batch (Batch)
Description Name of a configured transaction batch (or "none").
Default Value none

Property: entityIsolationLevel (Entity Isolation Level)
Description MISSING DESCRIPTION!

Property: method (Method)
Description Name and signature of method for method-specific application of this property, e.g. "myMethod(int, java.lang.String)".

Property: prefetch (Prefetch)
Description A comma-separated list of prefetch expressions. A prefetch expression is in the format "ParentEntity -> ChildEntity". If you are using a JIT driver wrapper with container-managed persistence, prefetch expressions may permit the persistence manager to reduce the number of database interactions by batching queries together. For example, in a transaction which fetches an order followed by the order lines, the prefetch expression "Order -> OrderLine" would enable a single query batch to be executed to retrieve all the necessary information in one database interaction.

See also: disablePrefetch (Data Source Property).

Property: readOnly (Read Only)
Description Specifies that this transaction is read-only. This information may be used by the persistence manager to optimize interaction with the database server, e.g. when using Sybase databases the selectWithUpdateLock property can be reduced dynamically to selectWithSharedLock to improve efficiency.

Note: you can be confident that use of the "readOnly" property will not change the semantics of your transaction, but it may change the performance characteristics. In particular, if you incorrectly specify "readOnly" for a read-write transaction, you may encounter database deadlocks requiring transaction rollback and retry, but this will not result in a loss of database consistency.

Default Value false
Legal Values false, true

Property: retry (Retry)
Description Specifies that the transaction manager may automatically retry this transaction if it is rolled back (for any reason, including use of the setRollbackOnly API).
Default Value false
Legal Values false, true

Property: retryCount (Retry Count)
Description Specifies the maximum number of retry attempts that will be performed by the transaction manager in the event of a rollback.
Only Used If Property retry has the value "true".
Default Value 2
Minimum Value 0
Maximum Value 2147483647

Property: retryDelay (Retry Delay)
Description Specifies the wait time (in milliseconds) between retry attempts that will be performed by the transaction manager in the event of a rollback.
Only Used If Property retry has the value "true".
Default Value 1000
Minimum Value 0
Maximum Value 2147483647

Property: sqlIsolationLevel (SQL Isolation Level)
Description Specifies the SQL isolation level for JDBC connections used from this transaction. Please refer to the Java documentation for class java.sql.Connection (method setTransactionIsolation).

The precise interpretation of this property (particularly "Serializable") is database-specific.

If you are using container-managed persistence, it is recommended in general that the SQL isolation level be "ReadCommitted" and that the isolationLevel Persistent Object Property or the isolationLevel Query Method Property be used to specify isolation level on a more fine-grained basis. This allows the persistence manager more options for database concurrency management, and thus may help you to obtain better performance.

Default Value ReadCommitted
Legal Values ReadUncommitted, ReadCommitted, RepeatableRead, Serializable

Property: type (Type)
Description Indicates the type of transaction management that is required by business methods.

  • BeanManaged - the business methods may access a UserTransaction object and perform explicit transaction demarcation.

  • Ignored - the container will not execute any transaction management at all. Portability Note: this is a non-standard option.

  • Mandatory - the container will check that a transaction is already in progress when calling business methods. Otherwise like "Required".

  • Never - the container will check that no transaction is in progress when calling business methods. Otherwise like "NotSupported".

  • NotSupported - the container will execute business methods in the context of a non-transaction. A non-transaction enables SQL autoCommit when accessing JDBC data sources.

  • Required - the container will execute business methods in the context of a transaction (either the current transaction if one exists already, or a new one). Any system-level exceptions thrown by business methods will result in transaction rollback.

  • RequiresNew - the container will execute business methods in the context of a new transaction. Any system-level exceptions thrown by business methods will result in transaction rollback.

  • Supported - the container will execute business methods in the context of the current transaction (if any). Any system-level exceptions thrown by business methods will result in transaction rollback.
Default Value Required
Legal Values BeanManaged, Ignored, Mandatory, Never, NotSupported, Required, RequiresNew, Supported