iBATIS transactional behaviour

["Konda, Sreenivasulu (Consultant)" <Sr...@Consultmail.net>]

Hi All,
 
I would like to know expected behaviour of iBATIS JDBC transactions.
Please see below code snippets and details for the same.
 
daoManager.startTransaction();
    insert("insertToTable1", Object1);
    insert("insertToTable2", Object2);
    update("updateTable3", Object3);
    delete("deleteFromTable1", Object1);
daoManager.commitTransaction();
 
Given above sequence of calls, assume that Thread1 is at
update("updateTable3", Object3) call and Thread2 too entered into the
same method where above exists.
 
Now
 
1) Will Thread2 be able to start another transaction before the tx1 got
committed to DB, which was started by Thread1?
2) If Thread2 starts tx2, what would be the behaviour at DB level in
this scenario?
3) If tx1 and tx2 are allowed simultaneously, is this called as nested
transaction?
 
BTW, transaction manager type is JDB as you see below XML tags from
sqlmap_config.xml.
 
<transactionManager type="JDBC">
    <dataSource type="JNDI">
      <property name="DataSource" value="java:comp/env/jdbc/abcDB"/>
    </dataSource>
  </transactionManager>
 
Please let me know your comments.
 
Thanks and regards,
Sreenivas
 
 

Re: iBATIS transactional behaviour

[Larry Meadors <lm...@apache.org>]

In iBATIS, transacitons are managed at the thread level - you call a
shared object, but it uses thread local storage to make it happen
under the covers.

Larry


On 11/4/05, Konda, Sreenivasulu (Consultant)
<Sr...@consultmail.net> wrote:
>
> Hi All,
>
> I would like to know expected behaviour of iBATIS JDBC transactions. Please
> see below code snippets and details for the same.
>
> daoManager.startTransaction();
>     insert("insertToTable1", Object1);
>
>     insert("insertToTable2", Object2);
>
>     update("updateTable3", Object3);
>
>     delete("deleteFromTable1", Object1);
> daoManager.commitTransaction();
>
> Given above sequence of calls, assume that Thread1 is at
> update("updateTable3", Object3) call and Thread2 too entered into the same
> method where above exists.
>
> Now
>
> 1) Will Thread2 be able to start another transaction before the tx1 got
> committed to DB, which was started by Thread1?
> 2) If Thread2 starts tx2, what would be the behaviour at DB level in this
> scenario?
> 3) If tx1 and tx2 are allowed simultaneously, is this called as nested
> transaction?
>
> BTW, transaction manager type is JDB as you see below XML tags from
> sqlmap_config.xml.
>
> <transactionManager type="JDBC">
>     <dataSource type="JNDI">
>       <property name="DataSource" value="java:comp/env/jdbc/abcDB"/>
>     </dataSource>
>   </transactionManager>
>
> Please let me know your comments.
>
> Thanks and regards,
> Sreenivas
>
>

Re:iBATIS transactional behaviour

[ooper <ma...@roomity.com>]

I suspect it depends on the rdbms being used and how it is configured; row level locks, page level locks, table level locks. I'm not
sure this is affected by iBATIS.

Scenario 1: Thread2 will be able to start a tx, but may have to wait for Thread1 to commit/rollback before it can commit/rollback. 
This depends on locking mechanism on the table(s). If the entire table is locked, thread2 will be waiting. If a row is locked, thread2
may be able to run simultaneously, granted the same row is not being updated.

Scenario 2: Depends on locking mechanism of involved tables, and whether the affected rows in thread1 and thread2 are the same.

Scenario 3: No, they are separate and distinct transactions.

I'd suggest reading up on how transactions and locking are handled by your rdbms.

Brian Barnett


------------------------------------------------------------------------------------------------------------------------------------------------
Broadband interface (RIA) + mail box saftey = <a href="http://iBatis_for_Java_Users_List.roomity.com">iBatis_for_Java_Users_List.roomity.com</a>
*Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131151519724~~
------------------------------------------------------------------------------------------------------------------------------------------------