There is and check box to enable JTS transactions under Profile -> Container -> Transactions. This action puts <jts/> tag under the transaction subsystem.
But for correct jts transaction initialization it is necessary to set attribute transactions to value 'on' in jacorb subystem as well. This is currently not happening.
This subsystem is accessible just in full and full-ha profiles.
This is probably not a console issue - it works the same way in CLI too. I would say that missing validation in underlying resource definition is the problem here.
It depends on the point of view.
Yes in CLI it works as you are saying but under cli I need to go under subsystem call method etc. It means that user exactly knows what he is doing - adding <jts/> tag element under transaction subsytem.
Console offers easy configuration to user - with graphical gui without needed to know what is exactly happening under the cover.
I would expect that when I set JTS to true in console that the jts would be correctly set (initialized). But this is not true.
We have a section to indicate user how to configure ORB for JTS with Management Console. If user follow the doc, I think they should be aware to this change.
Brian, can you comment on this? Dealing with cross subsytem constraints is not trivial on the console. Especially with RBAC in place.
Hi Brian, Hi Heiko,
I understand the possible technical problems but I consider this quite unhappy for users. Especially when you decide to change the transaction to jts when running the standalone.xml. The console permits do such change but restart will fail afterwards (as jacorb subsytem is not present).
Would be possible (as first step) add some note to the webconsole next to the parameter that the jts settings has some limitation?
The description text for the attribute that the server provides and that I *think* the console uses for tooltip text can include something about this. I'll have a look and see if I can get that in right now.
I updated the description.
Fixed as part of BZ1107869
*** This bug has been marked as a duplicate of bug 1107869 ***