1 Reply Latest reply on Aug 31, 2001 2:08 PM by Ian Butcher

    TX breakdown

    Ian Butcher Newbie


      I am having some interesting TX problems using JBoss 2.2.2. I have a
      reasonably complex TX which does the following:

      1. Find container entity A.
      2. For container entity A assign all contained entities to container entity
      B. (effectively an UPDATE operation on the contained entities table).
      3. Delete container A.

      To make this a little less abstract I have entities Phone and Phone
      Collection. Sometimes I want to delete a Phone Collection but move the
      Phones in that Phone Collection to another Phone Collection.

      **To get to the problem:**

      I update the variable in all of the Phone entities which assigns them to
      Phone Collection that I am about to delete to the Phone Collection that I
      want to re-assign to OK. I do some println s and they show that they now
      point to the new Phone Collection. However when I do the remove() on the
      the original Phone Collection I get a foreign key constraint violation.

      I have tried using Oracle 8.1.5. as the back end and Postgresql 7.1. but
      both give variations on the same problem.

      One thing that I have tried to try to fix the problem is change the
      transaction attribute on the method which changes which Phone Collection a
      Phone points to and made it RequiresNew (the main TX has Requires). My
      understanding is that this should cause the setPhoneCollection operation to
      execute in it's own TX (effectively within - the main TX) and therefore
      UPDATE the Phone database records before it tries to DELETE the Phone
      Collection record (therefore removing the FK violation). All this does it
      cause a deadlock until the TX times out.

      Any help very greatfully received,


        • 1. Re: TX breakdown
          Ian Butcher Newbie

          In addition I put some breakpoints in the my code and jboss and it seems that the container executes the remove jdbc command right after it happens - not in the order which is occurred in the TX. This really goings against serialization.