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() >