Re: CommitRequired attribute of transactionManager in iBatis 3

[Clinton Begin <cl...@gmail.com>]

In iBATIS 3, you can use .commit(boolean force)

The advantage is that you need not incur the performance penalty for every
transaction, and also, it allows frameworks like spring to declaratively
configure transactions to be forcefully committed.

Your thoughts?

Clinton

On Thu, Jan 28, 2010 at 1:42 PM, Eduardo M. Cavalcanti <
ecavalcanti@eversystems.com.br> wrote:

> Hello,
> The CommitRequired attribute of transactionManager, present in iBatis 2 is
> no longer necessary in iBatis 3?
>
> Quote from iBatis 2 manual:
>
> "The <transactionManager> element also allows an optional attribute
> commitRequired that can be true or
> false. Normally iBATIS will not commit transactions unless an insert,
> update, or delete operation has been
> performed. This is true even if you explicitly call the commitTransaction()
> method. This behavior
> creates problems in some cases. If you want iBATIS to always commit
> transactions, even if no insert,
> update, or delete operation has been performed, then set the value of the
> commitRequired attribute to true.
> Examples of where this attribute is useful include:
>
> 1. If you call a stored procedures that updates data as well as returning
> rows. In that case you would
> call the procedure with the queryForList() operation – so iBATIS would not
> normally commit the
> transaction. But then the updates would be rolled back.
> 2. In a WebSphere environment when you are using connection pooling and you
> use the JNDI
> <dataSource> and the JDBC or JTA transaction manager. WebSphere requires
> all transactions on
> pooled connections to be committed or the connection will not be returned
> to the pool."
>
>
> How to proceed in iBatis 3 in the example cases mentioned?
>
> Thank you.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>

Re: CommitRequired attribute of transactionManager in iBatis 3

["Eduardo M. Cavalcanti" <ec...@eversystems.com.br>]

Hello Clinton,
No repair.
I just wanted some clarification on this matter.
Thank you.


On 28/01/2010 17:22, Clinton Begin wrote:
> In iBATIS 3, you can use .commit(boolean force)
>
> The advantage is that you need not incur the performance penalty for 
> every transaction, and also, it allows frameworks like spring to 
> declaratively configure transactions to be forcefully committed.
>
> Your thoughts?
>
> Clinton
>
> On Thu, Jan 28, 2010 at 1:42 PM, Eduardo M. Cavalcanti 
> <ecavalcanti@eversystems.com.br 
> <ma...@eversystems.com.br>> wrote:
>
>     Hello,
>     The CommitRequired attribute of transactionManager, present in
>     iBatis 2 is no longer necessary in iBatis 3?
>
>     Quote from iBatis 2 manual:
>
>     "The <transactionManager> element also allows an optional
>     attribute commitRequired that can be true or
>     false. Normally iBATIS will not commit transactions unless an
>     insert, update, or delete operation has been
>     performed. This is true even if you explicitly call the
>     commitTransaction() method. This behavior
>     creates problems in some cases. If you want iBATIS to always
>     commit transactions, even if no insert,
>     update, or delete operation has been performed, then set the value
>     of the commitRequired attribute to true.
>     Examples of where this attribute is useful include:
>
>     1. If you call a stored procedures that updates data as well as
>     returning rows. In that case you would
>     call the procedure with the queryForList() operation – so iBATIS
>     would not normally commit the
>     transaction. But then the updates would be rolled back.
>     2. In a WebSphere environment when you are using connection
>     pooling and you use the JNDI
>     <dataSource> and the JDBC or JTA transaction manager. WebSphere
>     requires all transactions on
>     pooled connections to be committed or the connection will not be
>     returned to the pool."
>
>
>     How to proceed in iBatis 3 in the example cases mentioned?
>
>     Thank you.
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>     <ma...@ibatis.apache.org>
>     For additional commands, e-mail: user-java-help@ibatis.apache.org
>     <ma...@ibatis.apache.org>
>
>