Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Eclipse EMF Model Transaction Development Guide
Previous Page Home Next Page

Transaction Nesting

Both read-only and read-write Transactions can nest to any depth. The most common examples of transaction nesting occur in the commit phase of the transaction life-cycle: trigger commands are executed in nested read/write transactions and pre- and post-commit listeners are called in nested read-only transactions.

Post-commit listeners are called only when a root transaction (on that is not nested in some other transaction) commits. This is necessary because even after a nested transaction has committed, its changes can be rolled back if its parent (or some ancestor) rolls back. Pre-commit listeners are invoked at every level of nesting, because a parent transaction may assume the data integrity conditions guaranteed by triggers when it resumes following the commit of a child transaction.

Validation is performed on all changes when a root transaction commits, because it must include the changes performed by trigger commands in nested transactions. Validation has the last word in the committing of a transaction.

Inheritance of Transaction Options

The EMF Transaction API defines a number of standard options for read/write transactions. Nested transactions inherit these options from their parents. The standard options cannot be disinherited. For example, if a parent transaction does not send post-commit notifications, then none of its descendents will, either, even if they explicitly specify false for that option.

Nested transactions can, however, add options (set them true) that their parents do not have (or have them set false). For example, a child transaction can disable notifications. When its parent commits, the changes that it reports will simply exclude any that occurred during the execution of the child.

The inheritance of custom options in an extension of the transaction API is defined by that extension.

Copyright (c) 2006, 2007 IBM Corporation and others. All Rights Reserved.

  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire