Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

quick question on ejbRemove

 
Bob Walker Jr
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 114
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can set transaction attribute to requires new.
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic