In this case, I will not have any create() method in the home interface. Right?
How can I not have it availble to the clients? Or is it just immpossible?
I am sure the spec designers must have thought about it so there must be a simple way for CMP as well.
Originally posted by Lasse Koskela:
Can't you just say setRollbackOnly() in ejbRemove() (which is called before deleting the row from the database)? I haven't tried this but I guess it should rollback the delete operation...
Originally posted by Bob Walker Jr:
I think that's not a good idea because 1. you are fooling the client 2. You are rolling back the whole transaction while in reality you only want to rollback the deletion of the one row. 3. I am not sure what happens to the bean instance (in the app server) when ejbRemove() fails. But I suspect that the instance will be taken out of action and (probably) further client call on the reference will throw some exception. (Not sure abt that though).
Originally posted by Dave Cronin:
I think it may be better to just throw RemoveException in the first line of ejbRemove, either with BMP or CMP beans. The container should call the ejbRemove method before it tries to delete a CMP bean, so this means the RemoveException is thrown straight away. The client would then be notified that the remove operation is not allowed. I don't think it is necessary to call setRollbackOnly.
Another interesting point is that Weblogic have special read-only entity beans, but this is not part of the EJB spec.
The Container or Bean Provider is encouraged to mark the transaction for rollback only if data integrity
would be lost if the transaction were committed by the client. Typically, when a RemoveException is
thrown, it leaves the database in a consistent state, allowing the client to recover.
Originally posted by Pradeep Bhat:
It is required that a call be made to setRollbackOnly because the container would have removed the entry from db but not commited yet.
I think that there is no elegant method to avoid removing a entity.