2 Replies Latest reply on Mar 17, 2004 5:13 PM by grzegorzgłowaty

    long lived transaction problem

    grzegorzgłowaty

      Hello.
      Is there any way to implement a really long lived transaction in JBoss?
      What I'm trying to implement is a big import involving creation of thousands
      of entity beans (special bussiness logic is involved so it cannot be done by
      simple database tables import). I can guarantee that I'm the only user of
      Jboss working during this import so this transaction really doesn't need to
      lock anything. It only should allow ATOMICITY so it will be rolled back
      completelly if sth fails.
      I'm using JBoss 3.2.3
      On the default (Standard CMP) configuration I got "unable to passivate due
      to ctx lock" after the cache becomes full. Eventually it leads to "out of
      memory". It's obvious because Standard CMP uses pessimistic locking.

      So I tried to execute it on "Instance per transaction" configuration with
      NoLock and it no longer produces "unable to passivate" as it passivates
      beans, but memory used still grows up, but slower (the question here is why
      as the beans are passivated?) and finally I get "Out of memory exception".
      There's no possibility of a memory leak on my code because if I do the above
      in small transactions everything works fine.
      So my question is: how to assure the atomicity of the big import operation
      (as I mentioned I don't need any locking during the import as my import
      transaction is the only one performing in the system).

      Greetings,

      greg

        • 1. Re: long lived transaction problem
          cvandyck

          I have two session beans in the app I am developing that need hour or two hour long transaction times, so I code those with bean managed transaction stateless session beans.

          The other stateless session beans, that have container managed transactions, use the global default of 300 seconds.

          • 2. Re: long lived transaction problem
            grzegorzgłowaty

            Please read carefully what I've written above. My problem is not a transaction timeout (which I know how to deal with). My problem is out of memory due to instantiation and wrong(?) passivation of thousands entity beans. I described the problem in detail in my previous post.