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
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
