100 Databases and 1 Transaction - Websphere

This is a discussion on 100 Databases and 1 Transaction - Websphere ; Hey all, 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 ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: 100 Databases and 1 Transaction

  1. 100 Databases and 1 Transaction

    Hey all,

    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)

  2. Re: 100 Databases and 1 Transaction

    > 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


  3. Re: 100 Databases and 1 Transaction

    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.

  4. Re: 100 Databases and 1 Transaction

    > 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.


+ Reply to Thread