[Nitro] Request for Transaction example
Jonathan Buch
john at oxyliquit.de
Tue Jun 5 14:21:28 EDT 2007
Hi,
> explicitly setting :connection_count => doesn't yield what I expected
> either.... had thought that setting only one connection would force all
> transactions through that 1 and only connection...
in fact (in theory anyway) using a transaction while having :c_count on
1 would block the whole Thread (and so all Nitro/etc). This is because
the transaction gets one store from the pool, and when the User.create
wants its pool, it will block because there's no more stores in the
pool, waiting for stores to appear.
But, one iteration before this Manager, the manager leaked stores, just
creating new stores when there were no more stores in the pool, great
fun... I haven't looked in that area for quite some time now, maybe
I should do that more often...
So, this still could be happening, if the transaction/.create does not
block, there's something seriously wrong (nice for test case btw).
So, we need somehow a way to a) specify the store when using .save or
alternatively b) (using some very clever method I can't think of)
use the same store from transaction for database interactions within
a transaction.
idea:
def transaction
oldcrit = Thread.critical
Thread.critical = true
start
Thread.current[:transaction_store] = self
yield self
rescue Object => ex
rollback
Logger.debug "#{ex.class}: #{ex.message}"
ex.backtrace.each {|line| Logger.debug line}
Thread.current[:transaction_store] = nil
Thread.critical = oldcrit
else
commit
Thread.current[:transaction_store] = nil
Thread.critical = oldcrit
end
So, creating a critical section, and saving the store. This store
could then be used within store-consuming methods (like in the manager
handing out stores would always first try to get from
Thread.current[:transaction_store] instead of the pool.
Jo
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the Nitro-general
mailing list