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" <[EMAIL PROTECTED]>
To: "Chris McDonough" <[EMAIL PROTECTED]>; "Randall F. Kern"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
> To: "Randall F. Kern" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> 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" <[EMAIL PROTECTED]>
> > To: "Chris McDonough" <[EMAIL PROTECTED]>
> > 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:[EMAIL PROTECTED]]
> > > Sent: Monday, January 29, 2001 1:47 PM
> > > To: Chris McDonough; Randall F. Kern; [EMAIL PROTECTED]
> > > 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" <[EMAIL PROTECTED]>
> > > To: "Randall F. Kern" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > 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" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > 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  -  [EMAIL PROTECTED]
> > > > > 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  -  [EMAIL PROTECTED]
> > > > 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  -  [EMAIL PROTECTED]
> > 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 )
> >
> >
>
>
Index: SessionDataContainer.py
===================================================================
RCS file: 
/cvs-repository/Packages/Products/CoreSessionTracking/SessionDataContainer.py,v
retrieving revision 1.29
diff -r1.29 SessionDataContainer.py
241c241
<     
---
> 
249,250c249,250
<         return self._getContainer(parentpath, timeout).__of__(parent)
< 
---
>         return self._getContainer(parent, timeout).__of__(parent)
>         
261,262c261,265
< 
<     def _getConnection(self, parentpath):
---
>         
>     def _getConnection(self, parent):
>         db = self._v_db
>         if db is None:
>             db = self._getDB(self._v_parentpath)
264,269c267,272
<         if not conn:
<             db = self._v_db
<             if db is None:
<                 db = self._getDB(parentpath)
<             self._v_conn = db.open() # no versioning
<         return self._v_conn
---
>         if conn is None:
>             conn = self._v_conn = db.open() # no versioning
>             # if we don't have a jar yet, we steal our parent's
>             jar = self._p_jar or parent._p_jar
>             jar.onCloseCallback(ConnectionCloser(self, conn))
>         return conn
271,272c274,275
<     def _getContainer(self, parentpath, timeout):
<         conn = self._getConnection(parentpath)
---
>     def _getContainer(self, parent, timeout):
>         conn = self._getConnection(parent)
280c283
<     
---
>         
291a295,314
> class ConnectionCloser:
>     def __init__(self, mount, conn):
>         self.mount = mount
>         self.conn = conn
>         
>     def __call__(self):
>         """ This is called by the 'parent' connection's onCloseCallback
>         handler, so that our 'spawned' connection will be closed when
>         our parent connection is closed. """
>         # grab a ref
>         conn = self.conn
>         if conn is not None:
>             # Delete the parent's cached connection and our ref to mount.
>             self.mount._v_conn = None
>             # Remove circular reference.
>             self.conn = None
>             del self.conn
>             # Close the child connection.
>             conn.close()
>             

Reply via email to