[Zope] fix: CoreSessionTracking and ConflictError

Chris McDonough chrism@digicool.com
Tue, 30 Jan 2001 01:45:12 -0500


This is a multi-part message in MIME format.

------=_NextPart_000_02CD_01C08A5E.48F8FCD0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Wow, debugging that problem really sucked.  But it's fixed.

Thanks for reporting the problem, Randy, it'll be fixed in the next release
(which I will upload tomorrow)... alternately or in the meantime, you (and
anyone else with CoreSessionTracking 0.6) can use the attached patch to fix
the problem.

----- Original Message -----
From: "Chris McDonough" <chrism@digicool.com>
To: "Chris McDonough" <chrism@digicool.com>; "Randall F. Kern"
<randy@spoke.net>
Cc: <zope@zope.org>
Sent: Monday, January 29, 2001 6:09 PM
Subject: Re: [Zope] update: CoreSessionTracking and ConflictError


> This seems to be a problen with the SessionStorage part of the product...
it
> only occurs on accesses to the internal data container.  Using an external
> data container doesn't seem to exhibit the same problem.  I'll try to
> troubleshoot the SessionStorage....
>
> ----- Original Message -----
> From: "Chris McDonough" <chrism@digicool.com>
> To: "Randall F. Kern" <randy@spoke.net>
> Cc: <zope@zope.org>
> Sent: Monday, January 29, 2001 6:05 PM
> Subject: Re: [Zope] CoreSessionTracking and ConflictError
>
>
> > 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 )
> > > >
> > > >
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > 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 )
> >
> >
>
>

------=_NextPart_000_02CD_01C08A5E.48F8FCD0
Content-Type: text/plain;
	name="patch6to7.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="patch6to7.txt"

Index: SessionDataContainer.py=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A=
RCS file: =
/cvs-repository/Packages/Products/CoreSessionTracking/SessionDataContaine=
r.py,v=0A=
retrieving revision 1.29=0A=
diff -r1.29 SessionDataContainer.py=0A=
241c241=0A=
<     =0A=
---=0A=
> =0A=
249,250c249,250=0A=
<         return self._getContainer(parentpath, timeout).__of__(parent)=0A=
< =0A=
---=0A=
>         return self._getContainer(parent, timeout).__of__(parent)=0A=
>         =0A=
261,262c261,265=0A=
< =0A=
<     def _getConnection(self, parentpath):=0A=
---=0A=
>         =0A=
>     def _getConnection(self, parent):=0A=
>         db =3D self._v_db=0A=
>         if db is None:=0A=
>             db =3D self._getDB(self._v_parentpath)=0A=
264,269c267,272=0A=
<         if not conn:=0A=
<             db =3D self._v_db=0A=
<             if db is None:=0A=
<                 db =3D self._getDB(parentpath)=0A=
<             self._v_conn =3D db.open() # no versioning=0A=
<         return self._v_conn=0A=
---=0A=
>         if conn is None:=0A=
>             conn =3D self._v_conn =3D db.open() # no versioning=0A=
>             # if we don't have a jar yet, we steal our parent's=0A=
>             jar =3D self._p_jar or parent._p_jar=0A=
>             jar.onCloseCallback(ConnectionCloser(self, conn))=0A=
>         return conn=0A=
271,272c274,275=0A=
<     def _getContainer(self, parentpath, timeout):=0A=
<         conn =3D self._getConnection(parentpath)=0A=
---=0A=
>     def _getContainer(self, parent, timeout):=0A=
>         conn =3D self._getConnection(parent)=0A=
280c283=0A=
<     =0A=
---=0A=
>         =0A=
291a295,314=0A=
> class ConnectionCloser:=0A=
>     def __init__(self, mount, conn):=0A=
>         self.mount =3D mount=0A=
>         self.conn =3D conn=0A=
>         =0A=
>     def __call__(self):=0A=
>         """ This is called by the 'parent' connection's onCloseCallback=0A=
>         handler, so that our 'spawned' connection will be closed when=0A=
>         our parent connection is closed. """=0A=
>         # grab a ref=0A=
>         conn =3D self.conn=0A=
>         if conn is not None:=0A=
>             # Delete the parent's cached connection and our ref to =
mount.=0A=
>             self.mount._v_conn =3D None=0A=
>             # Remove circular reference.=0A=
>             self.conn =3D None=0A=
>             del self.conn=0A=
>             # Close the child connection.=0A=
>             conn.close()=0A=
>             =0A=

------=_NextPart_000_02CD_01C08A5E.48F8FCD0--