Can ejbRemove prevent the remove?

Discussions

EJB programming & troubleshooting: Can ejbRemove prevent the remove?

  1. Can ejbRemove prevent the remove? (8 messages)

    If i have a CMP entity bean and want to put in checking before allowing the client to delete it, can I put the checking in ejbCreate()? And if yes, how do I tell the container not to proceed with the remove? I just dont want to abort the whole txn so will not call setRollbackOnly(). Can throwing RemoveException in ejbRemove() achieve this?

    Threaded Messages (8)

  2. Can ejbRemove prevent the remove?[ Go to top ]

    typo, ejbCreate() should be ejbRemove()
  3. Can ejbRemove prevent the remove?[ Go to top ]

    If using CMP, there's no reason why you can't just ignore it, you don't even need to thrown an exception if you don't want. Just do nothing. However, take note of the fact that the bean is invalidated as soon as you call the ejbRemove, so you would need to get it again if you want it.

    If using BMP, I don't think you can do anything here. I may be wrong though.

    Jeff
  4. Can ejbRemove prevent the remove?[ Go to top ]

    Call me crazy, but shouldn't this response be reverse. If using BMP (because you control the delete) do nothing, if using CMP you're out of luck. If I'm wrong, please explain so that I can further understand EJB.

    Thanks.
  5. Call me crazy[ Go to top ]

    ... shouldn't this response be reverse? If using BMP ... do nothing, if using CMP you're out of luck.
    +1

    I also would like to know the answer to your question.

    Kind regards,
    Stefan
  6. Can ejbRemove prevent the remove?[ Go to top ]

    If i have a CMP entity bean and want to put in checking before allowing the client to delete it, can I put the checking in ejbCreate()? And if yes, how do I tell the container not to proceed with the remove? I just dont want to abort the whole txn so will not call setRollbackOnly(). Can throwing RemoveException in ejbRemove() achieve this?
    As an alternative, can you not put in a db trigger to check this (if the check has to done each and every time) and throw an Exception if the check fails. That way it will work whether you use an EJB container or a database tool to delete that database row. Just a thought ...

    Cheers<br>
    -raj
  7. Can ejbRemove prevent the remove?[ Go to top ]

    My initial thought is that you should probably limit access to the bean from the client so that it cannot access ejbRemove() directly. Who's your client, is it your own code or do you have third-party applications using your beans? You could always create your own remove method (which probably should be called something else) that you publish as the one to use. Either that or you just put a session facade in front which handles whatever check you want to make before you call ejbRemove() on the entity. I'm quite sure you cannot limit anything in the bean itself if you use CMP, since the implementation of the method is handled by the container.
  8. If i have a CMP entity bean and want to put in checking before allowing the client to delete it, can I put the checking in ejbCreate()? And if yes, how do I tell the container not to proceed with the remove? I just dont want to abort the whole txn so will not call setRollbackOnly(). Can throwing RemoveException in ejbRemove() achieve this?
    Entity Beans are designed to handle persistance logic, It can only create, store, retrieve and delete data. But you are trying to implement some kind of business logic on the CMP. So the best solution would be make your CMP as local and provide a Session Bean, which handles these kind of business logic and access your CMP.
  9. Can ejbRemove prevent the remove?[ Go to top ]

    If i have a CMP entity bean and want to put in checking before allowing the client to delete it, can I put the checking in ejbCreate()? And if yes, how do I tell the container not to proceed with the remove? I just dont want to abort the whole txn so will not call setRollbackOnly(). Can throwing RemoveException in ejbRemove() achieve this?
    The reason to insist checking be put into the entity bean itself is the 2 basic OO consideration: encapsulation and abstraction. If the remove checking logic is basic feature of the entity, I guess it would be more appropriate to attach the logic to the entity bean itself so that it becomes a abstract representation of the real life entity with the removal checking part of it. This make the logic always there even if we replace the session fascade with something else.

    Am I correct?