Kyler B. Laird writes:
... I was caching some information in my product using a global variable that started with _v_. Moving this to be self._v_cache solved the problem.
My *guess* is that something in the transaction machinery fails when there is data not tucked away in the proper place. .... So, the lesson is that I should avoid global variables in products, even if they appear to work otherwise. In principle, there is no problem with global data in modules. Many products do it to maintain non-persistent state that must be seen in all threads. Examples are my "CacheControlled ZSQL Methods", "FSSession" and "GUF".
Moving the information to "self._v_XXX" has the potential problem that it is only available to one thread: attributes starting with "_v_" are thread local! I would expect that you did not yet find the real problem. Dieter