Description: The unit of work is a session that implements all of the normal protocol of a TopLink session. It can be spawned from any other session including another unit of work. Objects can be brought into the unit of work through reading them or through registering them. The unit of work will opperate on its own object space, that is the objects within the unit of work will be clones of the orignial objects. When the unit of work is commited, all changes to any objects registered within the unit of work will be commited to the database. A minimal commit/update will be performed and any foreign keys/circular reference/referencial integrity will be resolved. If the commit to the database is successful the changed objects will be merged back into the unit of work parent session.
Responsibilities:
In the current design, this interface allows a use case to generate documents, while ensuring that only one instance of a document is created. This access is provided by the DocumentIdentityMap's DocumentFactory.
This interface may be extended in the future to allow for access to further types of business objects.
@version $Id: UnitOfWork.java 534530 2007-05-02 16:24:22Z andreas $Description: The unit of work is a session that implements all of the normal protocol of an EclipseLink session. It can be spawned from any other session including another unit of work. Objects can be brought into the unit of work through reading them or through registering them. The unit of work will operate on its own object space, that is the objects within the unit of work will be clones of the original objects. When the unit of work is committed, all changes to any objects registered within the unit of work will be committed to the database. A minimal commit/update will be performed and any foreign keys/circular reference/referential integrity will be resolved. If the commit to the database is successful the changed objects will be merged back into the unit of work parent session.
Responsibilities:
A UnitOfWork allows you to access Entities and work with them. All modifications to Entities are recorded by the UnitOfWork, and at the end they may be sent to the underlying EntityStore by calling complete(). If the UoW was read-only you may instead simply discard() it.
A UoW differs from a traditional Transaction in the sense that it is not tied at all to the underlying storage resource. Because of this there is no timeout on a UoW. It can be very short or very long. Another difference is that if a call to complete() fails, and the cause is validation errors in the Entities of the UoW, then these can be corrected and the UoW retried. By contrast, when a Transaction commit fails, then the whole transaction has to be done from the beginning again.
A UoW can be associated with a Usecase. A Usecase describes the metainformation about the process to be performed by the UoW.
If a code block that uses a UoW throws an exception you need to ensure that this is handled properly, and that the UoW is closed before returning. Because discard() is a no-op if the UoW is closed, we therefore recommend the following template to be used: UnitOfWork uow = uowf.newUnitOfWork(); try { ... uow.complete(); } finally { uow.discard(); } This ensures that in the happy case the UoW is completed, and if any exception is thrown the UoW is discarded. After the UoW has completed the discard() method doesn't do anything, and so has no effect. You can choose to either add catch blocks for any exceptions, including exceptions from complete(), or skip them.
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |