Oleg Broytmann a écrit :
conn = conn.transaction()

   creates a new transaction object; the object acquires a new low-level
connection from the pool and stores it; the low-level connection is removed
from the pool; "releasing" means "return it to the pool". For
single-threaded programs there is one connection in the pool.
  

  
Is it efficient? I mean, does it open a connection each time I make a
transaction?
    

   If the pool is empty a new low-level connection opened; if you have
disabled pooling (by setting conn._pool = None) the connection will be
closed instead of returning to the pool.

  
Why does it have to get a new connection? Why not using the current thread connection, as there can't be any other request made?

  
What about rollbacks? shoudn't they release the connection too? Or is it
always released?
    

   Yes. You can call as much .commit()'s, but after .rollback() you have to
call .begin() to acquire a new low-level connection. The last .commit()
should be called as .commit(True). Now you know why.

  
Ok, but you use the doInTransaction method and an exception occurs, the method calls rollback(). Shouldn'it release the connection to the pool also?
How can I detect that an exception occurred in the method? Even if I don't detect that, I think the connection should be released in all cases.

  
About caches, how is it possible that I don't have atomicity problems,
if  the row instance is the same object between threads, how can
transactions work correctly if I don't get the same read value because
of a commit not done in another thread?
    

   .commit() expires the object from all caches, so on the next access the
thread will redraw the object from DB. This doesn't work between processes,
of course.

  
If thread A changes in a transaction an instance value (without a forUpdate=True), but doesn't commit yet, and thread B access the same row instance (without a forUpdate=True). Isn't thread B supposed to read the old value of the instance? If thread B reads the same cached instance than A, it will update the sqlobject instance inside thread A with the old value, won't it?
My concern is that the transaction handling system in sqlobject works if you use a sql level read locking (forUpdate=True). But if you don't do that, the cache system can make things work not as you can expect. Am I right? (note that I'm a real newbie in sql transactions)
This may be why you need to use the sqlmeta cacheValues=False in this case?
   (Seems like a good piece of documentation. Need to insert this into
SQLObject.html...)

  
I found almost nothing about sqlobject transactions indeed.
Thanks