On 09/11/2013 02:28 PM, Jan Pazdziora wrote: > Which for typical web application request handling is what you want, > isn't it? The whole request processing is one transaction and > releasing it gives you nice cleanup.
It is, except for a very few cases of "commit-in-the-middle". > Does it happen in our code base? I confirm that in most cases, and in particular all cases we observed until now, this only happens in test code. > They need to be fixed to properly initialize the auth info in the logging > infrastructure. Indeed. I will send some patches to fix remaining cases I stumbled upon recently. In one case, for example, a ROLLBACK was issued after a test failed. This led to a subsequent code failing because the global Tcl variable would retain the log row id, but the corresponding row in the log table was gone! > No to the first part (we could use some other way), "I did not > find a better way" to the second part. Okay, I see the problem now. > The fact that the global variables are not initialized means that the > user of the database (the applications) broke the contract which > states that they should provide the auth logging information before > doing anything with the database session because *any* database table > can have logging enabled and need that information. That's the critical piece of information I was missing, as the LoggingFactory.clearLogId() method name and documentation were not terribly useful in understanding why it needs to be called after any operation on a new connection, COMMIT or ROLLBACK. Maybe I simply missed some documentation somewhere, I apologize in that case :) Thanks for the detailed explanation, -- Silvio Moioli SUSE LINUX Products GmbH Maxfeldstraße 5, 90409 Nürnberg Germany _______________________________________________ Spacewalk-devel mailing list Spacewalk-devel@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-devel
