[Nitro] Request for Transaction example

Jonathan Buch john at oxyliquit.de
Tue Jun 5 14:21:28 EDT 2007


> 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.


   def transaction
     oldcrit = Thread.critical
     Thread.critical = true
     Thread.current[:transaction_store] = self
     yield self
   rescue Object => ex
     Logger.debug "#{ex.class}: #{ex.message}"
     ex.backtrace.each {|line| Logger.debug line}
     Thread.current[:transaction_store] = nil
     Thread.critical = oldcrit
     Thread.current[:transaction_store] = nil
     Thread.critical = oldcrit

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.


Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

More information about the Nitro-general mailing list