How to have 2 Entity beans in the same transaction ?


EJB design: How to have 2 Entity beans in the same transaction ?

  1. Dear j2ee users,

    I need to use declarative transactions in my project.
    Unfortunately I cannot manage to have my transactions
    rolled back when there's an error. So this is

    my scenario:

    I have a Session bean Stateless with attribute:


    And 2 Entity beans with attributes:


    Now inside the session bean there's a method
    that calls the Entity bean create method

    void doMusic() {

    CD c = (CD)homeCd.create(50);
    Tape t = (Tape)homeTape.create(100);


    Now this is the matter- if the second bean (in this case Tape) fails (because of duplicate Primary Key) then the first create is NOT rolled back!!!
    Why it happens so ? I want that both "create" share the same
    transaction so I set up tx-Required in both of them.

    A last note: I'm using JBoss + PostgreSql as DB.
    I'd be very very grateful if someone gives me an advice.

    Thank you very much


  2. Hei F you can declare <trans-attribute>Required</trans-attribute> in the ejb-jar.xml for every bean.
    I think that the driven bean rolled back if an exception occours.
    Give me a feedback.
    Thanks Roger8
  3. Hope you are not catching this exception in you'r code... and if you are, you are doing a EJBContext.setRollbackOnly(); to signal a transaction rollback
  4. Hi all,
    thanks. I have solved the problem. It seems to be a bug with JBoss (the application server I'm using). I have to call "manually" setRollBackOnly in order to rollback the transaction, when there's a Create Exception.
    (Ps I just catch CreateException and RemoteException)

    Does anybody know if this behaviour is such also with other AS (Weblogic , Orion etc ) ?

  5. CreateException is one of the "application" exceptions and when it is thrown the container does not automatically rollback the transaction. This is mandated by the EJB API and every EJB container should behave like that!
  6. Eric is correct. These application exceptions enable the designer to decide whether he/she wants to abort the transaction. Depending on the business logic requirements such an event may be expected and so the dooming of the transaction may not be required.
  7. Ok thanks for your feedback. So for example how can I generate a non-application error that automatically instructs to container to rollback ? (Actually I expected that if I issue a create() - that violates a PRIMARY KEY constraint - then this should be regarded as a logic point to abort automatically the transaction and rollback previous statements...the problem is on the DB, not on the application)
  8. Catch the exception, and do whatever you want to do, e.g. do Context.setRollBackOnly() if you think you have come to the end your process if database insert fails, or simply change some values and try again. By not automatically rolling back the transaction, the EJB API gives the developers flexibility to handle this kind of exceptions.