Thank you very much for this detail...this is really good information as
three of our IT groups in the company are moving to the use of iBatis and
all need to understand this portion for working with distributed
transactions.
--
View this message in context:
What do these fields do in relation to allowing CMT to handle transactions in
iBatis?
The documentation is not totally clear, and from posts that I have read, I
am not sure if there is conflicting information. Does
commitRequired=false mean the container handles the transaction without
iBatis
I believe that with transactionManager type=EXTERNAL / they are
all moot - the external transaction manager is a no-op: it does
nothing.
Larry
On 6/27/06, jaybytez [EMAIL PROTECTED] wrote:
What do these fields do in relation to allowing CMT to handle transactions in
iBatis?
The
Some postings of iBatis makes it seem that if you want to give the container
full control of how commits are handled (and not iBatis), then you have to
do:
transactionManager type=EXTERNAL commitRequired=true
property name=DefaultAutoCommit value=false/
property
I am very confused about the transaction management also. I am not sure either if it works.I am using Oracle 9i and I have made several posts and it does not work. I cannot rollback operations. If I debug inside the daoManager then the code is suppose to roll back for all the contexts in the list.
The answers really depend on the type of transaction manager you are using - not the database.
If you use EXTERNAL, then commitRequired is irrelavant - it has no effect.
However, DefaultAutoCommit and SetAutoCommitAllowed still come into play because iBATIS may still use these values. If you
Another thing - DefaultAutoCommit and SetAutoCommitAllowed only apply to the EXTERNAL transaction manager. So, the truth table gets a little easier:
If SetAutoCommitAllowed=true, or not specified, then the auto commit property of the transaction will be set to whatever value you specify in the
