Chris McDonough wrote:

On Fri, 2004-03-19 at 02:02, Kevin Carlson wrote:

Chris McDonough wrote:

I guess that I don't understand why sessioning is causing this issue.


Neither do I, but I haven't really seen the code you're using, so it's
not really possible to deduce what's happening.

The code that I am using only checks values of variables held in the session. I need field level access control for some of the forms that I am displaying so I pass around a field level access code along with some other user information in the session. I have a bit of code in each of these forms (written in DTML) that checks the session variables and then displays only the items that they are allowed to see. The code never alters the information in the session, it is a read only operation.

The strange thing is that the code that is blowing up with the ZODB conflict error in Transience never touches the session so something, as you suggest, must be writing to the session implicitly but I have no idea what that might be.

Are you using Archetypes?  I found that it writes to the session on
every traversal of one of its objects.  Something is using sessions to
cause this, although it's hard to know what.

I'm not using the Archetypes product, but I am using custom content types in CMF 1.2. Well, not completely custom content types. What I did was copy an existing content type, rename it, and reset some of it's properties. Does retrieving CMF content type information from the catalog metadata cause this?

I am almost certain at this point that the problem lies within the sessioning machinery as I have another skin within CMF that does the same type of query but does not need the field level access information and does not use sessions in any manner. This particular skin runs it's page with no trouble at all. That begs the question to be asked: Does CMF use sessions and could that be a possible cause of this problem?

I am very appreciative of everyone's help with this problem. Any additional thoughts would be most welcome.

Kevin