5 Replies Latest reply on Oct 8, 2003 7:58 PM by the_bone_ranger

    EJB, Transaction etc

    Roger Tan Newbie

      I know that the EJB specs mentions that we should not do our own threading because of transaction, etc.
      Anyway, what if I want to do it ? Here's my question :
      1. Is it possible to spawn new threads and propagate the transaction context to the new threads ? I am currently doing my own readings but it might be helpful if someone can point to a website etc that contains an in depth technical discussion on why this is or is not possible.
      2. And believe me, I've taken a look at JMS as a solution, and this is indeed the direction that I am going with in the long run, but for the meanwhile I just want to do the following : spawn some threads to do my work and then call join on each of them. which seems quicker although admittedly the dangers are numerous.

      Thanks,



        • 1. Re: EJB, Transaction etc
          Adrian Brock Master

          How do you maintain transactional integrity when it is
          running concurrently?

          It is a rhetorical question.

          If you can guarantee the overall result of all operations
          are repeatable regardless of when they are run you
          won't have a problem.
          This is hard to do unless the operations share nothing
          at all.

          The JTA spec assumes it is impossible.
          Many parts of the JBoss container assumes a one-one
          mapping between transaction and running thread.
          A transaction can be associated with many threads at once,
          but only one thread can be a running state.

          JMS won't solve your problem. You can't do a send/receive
          in the same transaction. The send does not complete until
          the transaction commits. The receive will never happen.

          Regards,
          Adrian

          • 2. Re: EJB, Transaction etc
            Roger Tan Newbie

            Hi Adrian, let me give a background on why I am trying to do this. I have orders that are submitted in batches and I would like to process the orders in a batch in parrarel, collect the results of each and aggregate them as a batch result.
            I could only think of 2 architectures to do this ( we are using EJBs since most of our stuff is already in EJB ) :
            1. Use a JMS (MDB, etc ) based architecture with an
            aggregator in the end, which is
            ultimately what I will do in the long run. Transaction
            issue as I described on my previous post are
            ultimately not the most relevant issue here as you
            said.
            2. Spawn separate threads to process each order, call
            join for each of them and collect each individual
            result. Each order processing will ultimately result
            in some data specific to each order being created
            while some reference data is being read. My
            original thinking ( with regards to transaction ) was
            that it would be nice if I can roll back everything
            if I want to although they are on separate threads.
            Also I would like the reference data to be
            consistent.

            Can you clarify the following : "A transaction can be associated with many threads at once" ?

            Thanks

            • 3. Re: EJB, Transaction etc
              the_bone_ranger Newbie

              Maybe I'm missing the point here, but why don't you do the orders one at a time?
              Or is that too simple?

              Are you trying to speed things up? What you suggest (even if it were possible) doesn't sound like a good solution.

              • 4. Re: EJB, Transaction etc
                Roger Tan Newbie

                Correct I am trying to speed things up here. We are currently doing one order at a time which is too slow.

                • 5. Re: EJB, Transaction etc
                  the_bone_ranger Newbie

                  I assume that your hypothetical multithreaded request is not clustered and runs in the same JVM.

                  It probably won't speed things up much (if at all), I've tried doing this sort of thing as an experiment in a standalone data load app (on a multi processor machine with informix database).

                  What you wan't to do, is first get rid of any entity beans involved and use jdbc directly from a session bean. This will remove some overhead.

                  Then, look at optimising your sql, you'll find that cutting down the number of sql calls will speed things up.

                  Basically get rid of any overhead that will be multiplied by the number of orders.

                  And keep in mind how your database is supposed to process your transactions/multiple threads.