[Zope] CoreSessionTracking and ConflictError

[Chris McDonough]

OK, I think I've reproduced this.  But I haven't fixed it.  :-(  As soon as
I do, I'll let you know...

----- Original Message -----
From: "Randall F. Kern" <randy@spoke.net>
To: "Chris McDonough" <chrism@digicool.com>
Sent: Monday, January 29, 2001 5:28 PM
Subject: RE: [Zope] CoreSessionTracking and ConflictError


Yes, I mean I'm getting a conflict error on every access (for an
existing session), after a conflict.

I've read the docs, they are the best docs I've seen for anything Zope,
but they don't mention a reason why this might happen.

Any ideas?
-Randy

> -----Original Message-----
> From: Chris McDonough [mailto:chrism@digicool.com]
> Sent: Monday, January 29, 2001 1:47 PM
> To: Chris McDonough; Randall F. Kern; zope@zope.org
> Subject: Re: [Zope] CoreSessionTracking and ConflictError
>
>
> Oh, wait, I just reread that.  I only skimmed it first,
> sorry.  Are you
> saying that you get a conflict error on every access to the
> session mgr
> after you've had one conflict error?  I haven't experienced
> any failure mode
> like this.  Any concurrent write access to the session
> container has the
> possibility of causing a conflict.  getSessionData has the
> possibility of
> causing a conflict if a session key isn't found in the
> request because it
> creates a new session data object (e.g. if you run Apache's "ab" in
> concurrent mode against a method which calls getSessionData
> without giving a
> session key as part of the URL, you will get ConflictErrors
> because the
> container will be modified as new session objects are created).
>
> ----- Original Message -----
> From: "Chris McDonough" <chrism@digicool.com>
> To: "Randall F. Kern" <randy@spoke.net>; <zope@zope.org>
> Sent: Monday, January 29, 2001 4:38 PM
> Subject: Re: [Zope] CoreSessionTracking and ConflictError
>
>
> > There is info about this in the docs.
> >
> > ----- Original Message -----
> > From: "Randall F. Kern" <randy@spoke.net>
> > To: <zope@zope.org>
> > Sent: Monday, January 29, 2001 4:12 PM
> > Subject: [Zope] CoreSessionTracking and ConflictError
> >
> >
> > > I've been porting my product from my own private session
> manager to use
> > > CoreSessionTracking 0.6, and am having a problem with
> lots of conflict
> > > errors.
> > >
> > > I've got a session_id_mgr in the root, configured as per
> defaults, and a
> > > session_data_mgr also in the root, using the RAM base container.
> > >
> > > Then I have a simple DTML method:
> > >
> > > <dtml-let session="session_data_mgr.getSessionData()">
> > > <dtml-let title=title>
> > > <dtml-call expr="session.set('title', title)">
> > > <dtml-in expr="_.range(100)">
> > > <dtml-in expr="_.range(100)">
> > > </dtml-in>
> > > </dtml-in>
> > > </dtml-let>
> > > </dtml-let>
> > > Test
> > >
> > >
> > >
> > > If I goto this URL in a browser, it works fine,
> displaying "Test", with
> > > no ConflictError in my debug listing.  Then I quickly
> press Refresh
> > > twice in my browser.  This results in the page "Test", and a
> > > ConflictError in my log  (as I expected).
> > >
> > > After that, any request that uses the session data (even
> without a set)
> > > results in a ConflictError:
> > >
> > > <dtml-let session="session_data_mgr.getSessionData()">
> > > Title: <dtml-var expr="session.get('title')">
> > > </dtml-let>
> > >
> > >
> > > Any ideas why this is happening?
> > > -Randy
> > >
> > > _______________________________________________
> > > Zope maillist  -  Zope@zope.org
> > > http://lists.zope.org/mailman/listinfo/zope
> > > **   No cross posts or HTML encoding!  **
> > > (Related lists -
> > >  http://lists.zope.org/mailman/listinfo/zope-announce
> > >  http://lists.zope.org/mailman/listinfo/zope-dev )
> > >
> > >
> >
> >
> > _______________________________________________
> > Zope maillist  -  Zope@zope.org
> > http://lists.zope.org/mailman/listinfo/zope
> > **   No cross posts or HTML encoding!  **
> > (Related lists -
> >  http://lists.zope.org/mailman/listinfo/zope-announce
> >  http://lists.zope.org/mailman/listinfo/zope-dev )
> >
> >
>
>