A developer's guide to EJB transaction management
Overview
This article describes the principles of transaction management in an EJB from the perspective of a Java developer; that is, it explains what the developer has to do to take advantage of the transaction management facilities offered by the EJB1.1 specification.
Basic principles
It is important to understand the the EJB transaction system is designed to support the EJB paradigm. What I mean by this is that the designers had very clear ideas about how EJBs should be used. The specification may allow EJBs to be used in other ways, but the developer is out on a limb in these cases. In particular, the following basic assumptions are made:
This article describes the principles of transaction management in an EJB from the perspective of a Java developer; that is, it explains what the developer has to do to take advantage of the transaction management facilities offered by the EJB1.1 specification.
Basic principles
It is important to understand the the EJB transaction system is designed to support the EJB paradigm. What I mean by this is that the designers had very clear ideas about how EJBs should be used. The specification may allow EJBs to be used in other ways, but the developer is out on a limb in these cases. In particular, the following basic assumptions are made:
- An entity EJB is a representation of business data. Its state is represented completely by the values of its persistent instance variables, that is, those that are synchronized with the persistent store (database). If a transactional operation in such an EJB fails, then the system considers it to have been successfully rolled back if its underlying business data is put back to its pre-transactional state. Instance variables that do not represet data in the persistent store cannot be restored. If the EJB has container-managed persistence, then all the synchronization of the variables with the persistent store will be automatic, even after a rollback. This takes some work away from the developer, but it does imply that the EJB must be no more than an object representing a database row.
- Because of the assumption above, transaction management in entity EJBs should never be under programmer control. The EJB1.1 specification prohibits an EJB from managing its own transactions; the container must do everything. Therefore, if your transaction management requirements are beyond those offered by the container, then you can't use Entity EJBs at all. Of course, the EJB paradigm says that an entity EJB is simply a model of business data and, as such, will never need a more complicated transaction mechanism than that offered by the container.
- Where entity EJBs are involved in a transaction, the entity EJBs' methods will normally be called by a method in a session EJB.
ObjectDeletedException: deleted object would be re-saved by cascade (remove deleted object from associations)解决方法
org.hibernate.ObjectDeletedException: deleted object would be re-saved by cascade (remove deleted object from associations)解决方法：
1. To delete a Parent:
a. Make sure your Parent is not associated to any parent.
b. Delete the Parent and all connected Child will be too.
2. To delete a Child:
a. Remove the Child from the Sets from all Parentes asigned to.
b. Save the Parent which had the Child and the Child will be vanished too. (There is no need to delete it explicit.)
3. 删除Set方的cascade
4. 解决关联关系后，再删除 :
parent.getChildrens().remove(child);
child.setParent(null);
dao.removeChild(child);
5. 在many-to-one方增加cascade 但值不能是nonechild.setParent(null);
dao.removeChild(child);