Migration from 4.0.5 to 4.2.3

[Michal Glowacki]

I test migration from JBoss 4.0.5 to 4.2.3. It is not an easy task, many libs has changed, but there is one thing that hits my applications - JBossTS. I have couple of stateless session beans, that have methods with differet transaction attributes. In areas where I don't need transaction management I use data access objects. Now, my applications crashes on session beans, giving the exception:

"Adding multiple last resources is disallowed"

Great, I dig the web then and find solution at jboss.org:

"Wrap the resources in compensating transactions. See the Web Services transactions guides for further details.
Migrate the legacy implementations to two-phase aware equivalents. For DataSources deployed on JBoss Application Server, this is as simple as changing from <local-tx-datasource> to <xa-datasource>. See ConfigDataSources for more information.
Refactor the code to use separate transactions. If you simply need to read from one DataSource and insert processed results into another, you may not want or need 2-phase commit (and thus the above optimization). In an EJB3 session bean, this can be accomplished by simply delegating the read to a separate method and annotating it with @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW). This causes the calling method's Transaction to suspend, wait for the read to complete, and resume."

If I want to follow this instruction I have to change code in every place from DataSource object to XADataSource. Ok, I can live with this. But changing attribute to REQUIRES_NEW?! What for I have other types then?

Do I miss something? What I understand wrong? Is it really only way to upgrade my applications so it work under 4.2.3?

[Jaikiran Pai]

Originally posted by M Glowacki:
If I want to follow this instruction I have to change code in every place from DataSource object to XADataSource. Ok, I can live with this. But changing attribute to REQUIRES_NEW?! What for I have other types then?

If you are going to use a XADatasource then there won't be any need to change the transaction attribute to REQUIRES_NEW. But remember, that it's finally upto the business logic to decide which transaction attribute it needs to use. See the "Transaction Attributes" section in this document for details about transaction attributes.