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
> 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
I found almost nothing about sqlobject transactions indeed.