Transaction state bug?

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.