I'm running Rails 2.3.12 over MySQL and I believe I hit an incredibly odd scenario and wanted input on how this could be possible.
I had appear to have had a errant process that while handling a request go into a transaction, somehow fell out of it (this is the part I'm unclear on), then continued handling further requests while believing itself to be in a transaction. This caused the process so begin picking up DB locks everywhere without releasing them because the final commit never came through while handling new requests and this process also showed indications of having a stale view of the DB while actually working on incoming requests (boom). After killing and restarting the DB, this process began complaining about being unable to rollback to a save point. I'm fairly confident that the process handled a nested transaction request, fell out of child transaction but not the parent transaction and went on its very un-merry way. (All transactions, I believe, are nested with the require_new option to be true). I'm not a big expert on Rails so I'm curious how this could even be possible. It seems like it shouldn't given that transaction take place in blocks so the blocks shouldn't cross into multiple requests. If it is, shouldn't Rails check its transaction state between requests? Shouldn't it enforce that the state of a request begin without being in a transaction? Has this ever happened before to someone? Thanks. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-talk/-/4B7014PnWTgJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
