Re: [Modeling-users] ZEditingContextSessioning failing to init

[Paul M. <pau...@ma...>]

Hi S=E9bastien,

On 3-Mar-06, at 15:50 , S=E9bastien Bigaret wrote:

>     Hi Paul,
>
> Paul Mylchreest wrote :
>> Greetings,
>>
>> In the process of starting my zope server, getting this error:
>>
>> ------
>> 2006-03-03T10:29:05 ERROR(200) Products.ZEditingContextSessioning The
>> session data container's destruction callback already set --
>> installation aborted
>> ------
>
> The message you get is a security mechanism.
>
> It notifies you that an other Product (or maybe you) already set =20
> the destruction callback of the sessions data container.
> The ZECS (ZEditingContextSessionning) decides not to override it =20
> when it is already set, because if you (or another Product) already =20=

> rely on it, some special action needs to be taken (namely: calling =20
> the already registered callback before or after ZECS's one).
>
> Frankly, you're the 1st person reporting such a collision; I =20
> suspect that the zeo configuration is the reason.
>
> Could you please tell us which callback is registered: in the ZMI, =20
> go to /temp_folder/session_data and look at the value entered under =20=

> the field 'Script to call when objects are deleted' ?  I appreciate =20=

> your time --hopefully we'll quickly find a fix for the problem.
>

The registered callback is: "/Control_Panel/Products/=20
ZEditingContextSessioning/sessionDeletion_hook"

Starting to understand what happened. At some point, I split my dev =20
server into a zeoserver config, but with ZECS already installed.

Here's what I did: uninstall ZECS, clear the callback and reinstall. =20
Restarting Zope, no error and the callback is set.

Next, create another zeoclient and start it: now I get the security =20
warning.

I think this is happening because the session is now stored in zodb =20
storage, and not in the instance's home temp storage.

Thanks for your help S=E9bastien,

> In the meantime, if you want to try the ZECS despite the problem, =20
> just apply the attached patch: the installation won't be stopped =20
> because of that situation.  Be aware, however, that the patch =20
> shouldn't be installed in a production environment if you're using =20
> SESSION.defaultEditingContext: if the deletion hook is not properly =20=

> installed, then a session's EC will never be garnaged collected =20
> when a session expires, causing the memory footprint to grow, and =20
> grow, and grow!
>
> In a test/dev environment this should not be a problem however.
>
> -- S=E9bastien.


Paul,=