EJB, Transaction etc

[divine_comedy]

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,

[adrian.brock]

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

[divine_comedy]

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

[the_bone_ranger]

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.

[divine_comedy]

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

[the_bone_ranger]

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.