quick question on ejbRemove

[Bob Walker Jr]

Let's say my app does not provide any way to create new beans for an entity. They are created by some other process in the database. In this case, I will not have any create() method in the home interface. Right?
Now, if I don't want the clients to remove the beans either, how do I do it? I am confused because if a client is not allowed to create a bean, it is legitimate for it not to delete it. But the remove() method is declared in EJBHome interface. How can I not have it availble to the clients? Or is it just immpossible?
Kindly help!!!

[Pradeep bhatt]

In this case, I will not have any create() method in the home interface. Right?

You are right

How can I not have it availble to the clients? Or is it just immpossible?

If you are using BMP, do not write any code in ejbRemove and may throw RemoveException. In case of CMP, I guess it is tough to do that . If you are using a database like Oracle you can write a trigger that does not delete a database row. I have not yet tried this one. May be you can try and give us the update.
It is not possible to hide the remove method from the client because EJBObject is an interface.
[ August 12, 2003: Message edited by: Pradeep Bhat ]

[Bob Walker Jr]

Thanks Pradeep. I am sure the spec designers must have thought about it so there must be a simple way for CMP as well.

[Lasse Koskela]

I am sure the spec designers must have thought about it so there must be a simple way for CMP as well.

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...

[Pradeep bhatt]

Lasse, you are right.
This method and the database delete operation(s) execute in the transaction context determined by the transaction attribute of the remove method that triggered the ejbRemove method.
The spec designers are clever guys.

[Bob Walker Jr]

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...

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).

[Pradeep bhatt]

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).

The bean will not be taken out of instance unless it throws some SystemException.

[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.

[Bob Walker Jr]

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.

Interesting. So it seems that there is no way we can make sure that the client does not call the remove() method on the bean.
The reason I am complaining is that a client code may be written for a 3rd party bean. And so the client code will easily compile even if it calls remove and will bomb only at run time. It is totally inconsistant with the create methods, in which case the client will not even compile.
If there is no clean way of doing it then can I say that EJB designers were...ummm...not clever enough Or is there some specific reason why they chose not to deal with this issue the way they dealt with the create issue?

[Pradeep bhatt]

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.

[Dave Cronin]

There really does not seem to be a clean way to handle this scenario. There is no compile-time check, only a runtime check is possible. From the EJB spec v2.1, it says that read-only entity beans are planned for a future release. Probably they couldn't agree on the standard, but I think it would be a useful feature.
About rolling back the transaction, I would say that if you throw RemoveException from ejbRemove, the exception throws the control flow directly out of the method, and the container thus never attempts to delete the entity. The calling client still has to deal with the exception though. From the EJB spec about RemoveException and rollback, it says

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.

[Rangarajan Suresh]

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.

You can not call setRollbackOnly() without considering what else has occurred in the same transaction.
If a 3rd party is going to use your beans, you can mention in the Docs that calling remove on the bean will not remove the entity and should be handled by the calling client.

[Pradeep bhatt]

You can set transaction attribute to requires new.