Re: [Modeling-users] ZEditingContextSessioning failing to init

[<sbi...@us...>]

Thanks for all the precisions; this is definitely a situation that should=
 be detected and handled by the product.=20

I've opened ticket #1442766 for that.
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1442766&grou=
p_id=3D58935&atid=3D489335

If you have some time, could you try the attached patch (replacing the on=
e sent earlier) ?

I've had some tests and more zLog statements: I've no zeo env. at hand, I=
 have no time for trying to set up one and I do not have any real experie=
nce w/ zeo environments, so if you could install this patch and report th=
e observed logs for the second zeoclient, that will be a great help for m=
e to fully understand how zeo works.  In particular, I'd like to determin=
e whether TransientObject is also shared and correctly setup or not --I t=
hink it is not, and, well, we'd better be sure! or the second, 3rd etc. z=
eo instances won't have any SESSION.defaultEditiingContext.

-- S=E9bastien.


PS: LOG statements at the INFO level for the purpose of verifications --t=
hey should be DEBUG or BLATHER when committed.

Paul Mylchreest a =E9crit :
> Hi S=E9bastien,
>=20
> On 3-Mar-06, at 15:50 , S=E9bastien Bigaret wrote:
>=20
>>     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 the
>> destruction callback of the sessions data container.
>> The ZECS (ZEditingContextSessionning) decides not to override it when
>> it is already set, because if you (or another Product) already rely on
>> it, some special action needs to be taken (namely: calling the already
>> registered callback before or after ZECS's one).
>>
>> Frankly, you're the 1st person reporting such a collision; I suspect
>> that the zeo configuration is the reason.
>>
>> Could you please tell us which callback is registered: in the ZMI, go
>> to /temp_folder/session_data and look at the value entered under the
>> field 'Script to call when objects are deleted' ?  I appreciate your
>> time --hopefully we'll quickly find a fix for the problem.
>>
>=20
> The registered callback is:
> "/Control_Panel/Products/ZEditingContextSessioning/sessionDeletion_hook=
"
>=20
> Starting to understand what happened. At some point, I split my dev
> server into a zeoserver config, but with ZECS already installed.
>=20
> Here's what I did: uninstall ZECS, clear the callback and reinstall.
> Restarting Zope, no error and the callback is set.
>=20
> Next, create another zeoclient and start it: now I get the security
> warning.
>=20
> I think this is happening because the session is now stored in zodb
> storage, and not in the instance's home temp storage.
>=20
> Thanks for your help S=E9bastien,
>=20
>> In the meantime, if you want to try the ZECS despite the problem, just
>> apply the attached patch: the installation won't be stopped because of
>> that situation.  Be aware, however, that the patch shouldn't be
>> installed in a production environment if you're using
>> SESSION.defaultEditingContext: if the deletion hook is not properly
>> installed, then a session's EC will never be garnaged collected when a
>> session expires, causing the memory footprint to grow, and grow, and
>> grow!
>>
>> In a test/dev environment this should not be a problem however.
>>
>> -- S=E9bastien.
>=20
>=20
> Paul,