Skip Headers

# Clones and the Unit of Work

Previous

Next

When using the `DefrerredChangeDetectionPolicy` or the `ObjectLevelChangeTrackingPolicy` (see "Deferred Change Detection Policy"), the unit of work maintains two copies of the original objects registered with it:

- Working clones

- Backup clones

After you change the working clones and the transaction is committed, the unit of work compares the working clones to the backup clones, and writes any changes to the database. The unit of work uses clones to allow parallel units of work (see "Nested and Parallel Units of Work") to exist, a requirement in multiuser three-tier applications.

The TopLink cloning process is efficient in that it clones only the mapped attributes of registered objects, and stops at indirection objects unless you trigger the indirection. For more information, see "Configuring Indirection".

You can customize the cloning process using the descriptor's copy policy. For more information, see "Configuring Copy Policy".

Never use a clone after committing the unit of work that the clone is from (even if the transaction fails and rolls back). A clone is a working copy used during a transaction and as soon as the transaction is committed (successful or not), the clone must not be used. Accessing an uninstantiated clone value holder after a unit of work commit transaction will raise an exception. The only time you can use a clone after a successful commit transaction is when you use the advanced API described in "Resuming a Unit of Work After Commit".