It is unlikely that the the low conflict connection causes your problem. "Low conflict" affects the following situation:
You try to load an object (because it is not in your ZODB cache) and get informed that is has been modified (by another commited transaction) since your transaction started.
With a normal ZODB connection, you will get a "ReadConflictError" as adding the object to your ZODB cache would make it inconsistent: some objects would have the state from your transactions start and others from a later date. With a low conflict connection, the inconsistency is accepted and no "ReadConflictError" is raised.
As you described, you loose the session object. This is not easily understood as the effect of a cache inconsistency.
Sure. Disabling Low conflict hasn't solved anything. I'm not able to find where is the problem. I have not enought knowledge of Zope internals. I will try to store my data in persisten subobjects, as you said. One thing is true: Changing session object simultaniously in various frames doesn't work fine. Sometimes session data is not the espected becouse another frame has erased your changes in the session object. I think this is a serious inconvenient in front of other platforms.
From my point of view, it would be better to have SESSION out of the transaction but with changes stored inmediatly. You don't?
Perhaps some day I will be able to implement this for myself. Until that, do you think I should enter a bug, or this cann't be considered as a bug? Thanks for your help Santi Camps