> I have over 100 databases to update in a two phase commit transaction.
> Doing the update sequentially for ten database instances takes around
> two minutes, whereas doing the updates in parallel takes around
> thirteen seconds no matter how many databases are involved. In case
> you're wondering, the databases contain different schemas, and I'm
> doing Proof of Concepts in order to inform the current decision-making
> process on this issue.
>
> In JBoss I've managed to enlist multiple threads into a single XA
> Transaction by using the TransactionManager retrieved from JNDI to get
> the active Transaction and then using the resume(Transaction) method
> when spawning threads to enlist a thread into the existing
> transaction.
>
> Does anyone know if I can do the same in WebSphere, or if there is
> something else that can be used for the same effect? (Googling on
> appropriate keywords hasn't revealed anything useful so far)

First keywords coming to mind are CommonJ WorkManager and Asynchronous
Beans.

http://www.ibm.com/developerworks/we...6_johnson.html

Thanks for the quick (and very informative!) response, the
WorkManager / Asynchronous Beans looks ideal apart from one issue -
http://www.devwebsphere.com/devwebsp...beans_book.doc
(linked from http://www.javaworld.com/javaworld/j...1-workmgr.html
) states that the work items will run in their own local transaction.
Having the rest of the context is great (much better than the stuff I
have at the moment), but access to the same global transaction is the
'make-or-break' thing here

I'll keep looking at this, esp. as I think the whole WorkManager / JSR
237 would make the contents of the proof of concept a little more
standardised than creating threads manually.

> work items will run in their own local transaction.

I'm not too familiar with the subject, but when this is the case, it's
somewhat dispointing indeed...

Here is an exceprt from the InfoCenter:
"
Every asynchronous bean method is called using its own transaction, much
like container-managed transactions in typical enterprise beans. It is very
similar to the situation when an Enterprise Java Beans (EJB) method is
called with TX_NOT_SUPPORTED. The runtime starts a local transaction before
invoking the method. The asynchronous bean method is free to start its own
global transaction if this transaction is possible for the calling J2EE
component. For example, if an enterprise bean creates the component, the
method that creates the asynchronous bean must be TX_BEAN_MANAGED.

When you call an entity bean from within an asynchronous bean, for example,
you must have a global transactional context available on the current
thread. Because asynchronous bean objects start local transactional
contexts, you can encapsulate all entity bean logic in a session bean that
has a method marked as TX_REQUIRES or equivalent. This process establishes a
global transactional context from which you can access one or more entity
bean methods.
"
(http://publib.boulder.ibm.com/infoce...b_asbover.html)

There is also here an ancient discussion on the subject:
http://www.theserverside.com/news/th...hread_id=35626.

Interesting but better not trust as such and verify if it's still valid for
WAS 6.1.

HTH.