static SqlMapClient and transaction isolation problem

[User 080701]

If I create a static SqlMapClient to service many threads, does ibatis guarantee transaction isolation ?

e.g. If one thread start the transaction and not commit,
      if another thread start the transaction using the same sqlMapClient, does it throw transaction already start exception ?

[Rick.Wellman]

Unfortunately I cannot dive into the many details of iBatis and
transactions but here is how I would answer your question:
1) You almost assuredly want to create a single static SqlMapClient to
service many threads.  
2) I am pretty sure that iBatis uses ThreadLocal to isolate transactions
from different threads which is why it works so well with webapps.
However, I am admittedly on the learning curve myself in this regard so
if someone could agree/refute/augment my answer, then I would appreciate
it :)

-----Original Message-----
From: User 080701 [mailto:user080701@...]
Sent: Thursday, October 22, 2009 10:04 AM
To: user-java@...
Subject: static SqlMapClient and transaction isolation problem


If I create a static SqlMapClient to service many threads, does ibatis
guarantee transaction isolation ?

e.g. If one thread start the transaction and not commit,
      if another thread start the transaction using the same
sqlMapClient,
does it throw transaction already start exception ?
--
View this message in context:
http://www.nabble.com/static-SqlMapClient-and-transaction-isolation--pro
blem-tp26011592p26011592.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[Larry Meadors]

On Thu, Oct 22, 2009 at 9:03 AM, User 080701 <user080701@...> wrote:
>
> If I create a static SqlMapClient to service many threads, does ibatis
> guarantee transaction isolation ?

yes.

> e.g. If one thread start the transaction and not commit,
>      if another thread start the transaction using the same sqlMapClient,
> does it throw transaction already start exception ?

no.

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...

[nmaves]

Ibatis 2.x does use ThreadLocal to handle the transactions.  With ibatis 3 you need to handle this on your own right now but we have been playing with a few ways to use ThreadLocal with it as well.  I actually have a pretty clean working webapp using it.

On Thu, Oct 22, 2009 at 9:09 AM, Rick.Wellman <Rick.Wellman@...> wrote:

Unfortunately I cannot dive into the many details of iBatis and
transactions but here is how I would answer your question:
1) You almost assuredly want to create a single static SqlMapClient to
service many threads.
2) I am pretty sure that iBatis uses ThreadLocal to isolate transactions
from different threads which is why it works so well with webapps.
However, I am admittedly on the learning curve myself in this regard so
if someone could agree/refute/augment my answer, then I would appreciate
it :)

-----Original Message-----
From: User 080701 [mailto:user080701@...]
Sent: Thursday, October 22, 2009 10:04 AM
To: user-java@...
Subject: static SqlMapClient and transaction isolation problem


If I create a static SqlMapClient to service many threads, does ibatis
guarantee transaction isolation ?

e.g. If one thread start the transaction and not commit,
     if another thread start the transaction using the same
sqlMapClient,
does it throw transaction already start exception ?
--
View this message in context:
http://www.nabble.com/static-SqlMapClient-and-transaction-isolation--pro
blem-tp26011592p26011592.html
Sent from the iBATIS - User - Java mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@...
For additional commands, e-mail: user-java-help@...