Is SqlMapClient threadsafe?

[nilesh]

As per the SQLMap javadocs --

An SqlMapClient instance can be safely made static or applied as a Singleton.

Now my qns is how will the following code work in a multithreaded environment with a singleton instance of SqlMapClient?

try
{
   sqlMap.startTransaction()
   Employee emp2 = new Employee();
   Integer generatedKey = (Integer) sqlMap.insert ("insertEmployee", emp2);
   emp2.setFavouriteColour ("green");
   sqlMap.update("updateEmployee", emp2);
   sqlMap.commitTransaction();
}
finally
{
   sqlMap.endTransaction();
}

Let say thread T1 starts a transaction on the SqlMapClient instance. Thread T2 also tries to access the same instance. Now what will happen if T2 also starts the transaction before T1 ends?

[Kris Jenkins]

They'll get two seperate transactions, and will obey the transactional rules of your database (and your database's JDBC driver).  SqlMap will not cause any complications.

<bonus answer>
...unless you've set maxTransactions to 1.  In which case the second call would block until the first had completed.
</bonus answer>

Does that help?
Kris

[nilesh]

Kris,
Thanks for your quick response...

Although, I'm still not clear how would SqlMapClient know to maintain 2 different transactions?

startTransaction() doesn't return back anything...so when endTransaction() is called, how would SqlMapClient determine if its being called by thread T1 or by T2?

Well... I guess i should dig into iBatis source code till I find out how does the single instance of SqlMapClient maintain different transaction scope per thread..

~ Nilesh

[Larry Meadors]

It uses ThreadLocal to mange thread safety.

[nilesh]

Larry, Thanks !!!

iBatis dev. guide also specifies that ThreadLocal is used to make SqlMapClient threadsafe... I should have read carefully before posting a qns!

Note! SqlMapClient transactions use Javas ThreadLocal store for storing transactional objects. This means that each thread that calls startTransaction() will get a unique Connection object for their transaction. The only way to return a connection to the DataSource (or close the connection) is to call commitTransaction() or endTransaction(). Not doing so could cause your pool to run out of connections and lock up.

[Larry Meadors]

Ya, ThreadLocal is good magic. I like it. :)

[Brandon Goodin]

THIS IS A USER SUPPORT QUESTION AND IS NOT RELATED TO THE DEVELOPMENT OF THE IBATIS FRAMEWORK. PLEASE POST ON THE USER SUPPORT FORUM IN THE FUTURE.