On Tue, Jun 07, 2011 at 01:29:33PM +0200, Andreas Rogge wrote: > > I don't think so. I guess the best way to go is: > > call the handler > if all went well, commit
Yes but do that within the handler, not in apacheHandler.py, which is the "framework" around the handlers. If the handler ended and did not commit, we (apacheHandler.py) really have no business committing for that handler. > if something failed, rollback > > That's what the code above does. If anything goes really wrong the > handler should throw an exception and the transaction will be rolled > back. > > The right way to fix this would be to trace *all* handlers and see > which one leaves dangling transactions behind. Right, that's my goal. By doing rollback, I hope to find the faulty applications (handlers) that don't commit properly, by rolling-back their work and thus turning them into noop. > There is probably a reason that transactions are only rolled back > when an exception inside the handler occurs. Well, they have to be rolled back because if exception is thrown in the Python stack, something went really wrong in Python, yet the database connection does not know about it. > I think addition of a commit right here is the least intrusive way > to work around the issue (especially as there already is an > oracle-workaround one line below). I'd call it a quick fix which can potentially hurt us in the long run. > I have no idea wether there's a way to ask the PostgreSQL/Oracle > session wether there is uncommitted work and/or a transaction open. > If there is a way to check this, we could just log detailed > warning-messages when a handler returns and rhnSQL has an open > transaction. I'll try to check this, good point. -- Jan Pazdziora Principal Software Engineer, Satellite Engineering, Red Hat _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
