Al­low Sub­trans­ac­tions: En­able or Not?

What are the pros and cons of tweak­ing this pa­ra­me­ter?

Al­low­ing Sub­trans­ac­tions

You may have no­ticed that we have the fol­low­ing start­up con­fig pa­ra­me­ter (in jta.prop­er­ties):

com.atomikos.icatch.allow_subtransactions=true

Even if you don't have it in your con­fig, it still ex­ists as a de­fault.

What It Does

What does this do, and why would you ever want to dis­able it? When en­abled, you can have uses cas­es like this one:

UserTransactionManager utm = new UserTransactionManager();
tx1 = utm.begin();
tx2 = utm.begin();
//exception in tx2
tx2.rollback();
//try alternatives to tx2's logic
tx1.commit();

In par­tic­u­lar, you can start a trans­ac­tion tx2 (a "sub­trans­ac­tion") in­side an ex­ist­ing trans­ac­tion tx1 (the "par­ent") and have tx2 roll­back in­de­pen­dent­ly. When that hap­pens, tx1 can still try some al­ter­na­tive log­ic and com­mit. This al­lows more ad­vanced ex­cep­tion han­dling in­side tx1.

What hap­pens if tx2 com­mits in­stead? Like this:

UserTransactionManager utm = new UserTransactionManager();
tx1 = utm.begin();
tx2 = utm.begin();
//exception in tx2
tx2.commit();
tx1.commit();

In this case, the com­mit of tx2 es­sen­tial­ly marks its re­source ac­cess­es for in­clu­sion in the fi­nal com­mit of tx1. In oth­er words, com­mit of a sub trans­ac­tion does not do any­thing spe­cial be­sides de­lay­ing the com­mit to the par­ent.

When Dis­able This?

There are 2 cas­es when sub­trans­ac­tions may not be ide­al:

• If tx2 needs to see the up­dates of tx1 - this may or may not block de­pend­ing on the case DBMS dri­vers and the use case.
• If your ap­pli­ca­tion is bug­gy and leaves tx1 pend­ing - so it is reuse for a lat­er re­quest if you have thread pool­ing. This can give hard-to-find is­sues where lat­er re­quests are re­al­ly ex­e­cut­ed in­side the scope of a pre­vi­ous trans­ac­tion.