Managing transactions

The Update*( ), Create*( ), and Delete*( ) service methods normally commit the changes for an object in a single transaction. As shown above, the Create*( ) and Update*( ) methods support both a single entity and a collection of entities. A collection passed to an Update*( ) service method can include new entities, changes to entities, and entity deletions.

The transaction includes changes to entities in any of the child collections of the entities that are passed to the service method. However, the properties and child collections of an entity are not rolled back in the event of a transaction rollback.

CAUTION: The service requires a connected database, and subsequent transactional methods can span the physical transaction. This means that it is possible to use the TRANSACTION option on a block and increase the transaction scope to span more than one service call. This, in principle, is an unsupported mode of operation. Attempting to use the TRANSACTION option around one of the few methods that require two transactions will prevent the second transaction from taking place (see Table updates that require two transactions), but there is no known reason why it should not work for other methods as long as the transaction does not span multiple services. If the services are connected to different databases, the operation would be a two-phase commit. However, the effect of a transaction that spans multiple instances on the same database is quite unpredictable.

The API is designed to run separately from the database in a future release, and code that has functionality that relies on the TRANSACTION option will likely not be able to run separate from the database in the future. Note that the API design is based on a common OpenEdge application strategy, and the warning against using the TRANSACTION option is consistent with OpenEdge recommendations for implementing a business logic layer in ABL; there are no current plans to support the API in a distributed application environment.