Re: [Modeling-users] ZEditingContextSessioning failing to init

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

Paul Mylchreest a =E9crit :
> Hi again,
>=20
> I applied the patch and here are the logs (I deleted the registered
> callback):

[...] Ok, thanks

> Also, when tracing defaultEditingContext(), each server seems to return
> a different EC.
>=20
> Server1: session.id: 11414313110001400458 ec:
> <Modeling.EditingContext.EditingContext object at 0x284b0f0>
> Server2: session.id: 11414313110001400458 ec:
> <Modeling.EditingContext.EditingContext object at 0x26bb9d0>
>=20

Oh well, I guess the documentation lacks an important paragraph here.

The ZECS is designed to work in a MT environment, not in different
instances. That's why you get this, hopefully you noticed it.

The fact is that, you cannot share EC between different processes (so
this is not specific to zeo itself).  To do such a thing, it would be
necessary to store the EC in the session along with its pending
insertions/deletions, and the whole graph of objects as well since
pending modifications can exist in-memory.  It is not possible in the
current implementation, and there is no plan for making this available
(for example, in the zope/zeo case, this means
that every single object and their attributes should be made
zodb-Persistent so that they can be stored in a session object).


In fact, Zope/zeo & zodb address the same problem by opening and closing
a  transaction changes at the beginning/end of each request loop. If you
need to hold back changes between two or three requests/pages, you won't
change the real object in the "main" zodb, rather you'll store the
changes in a session object.

- If every changes made in a request loop is committed/rolled back at
the end of the request, then you'll made changes directly in the object.
You can do the same w/ ZECS: this is why it has an option binding
EC-transactions to zope transactions, cf.
http://modeling.sf.net/UserGuide/framework-integration-zope-options.html

- on the other hand, if the modifications of, say, a given objet should
be made accross different requests/pages before being permanently stored
in a db (either zodb, or rdbms), you'll just make it the usual way; e.g.
storing the changes in a session-object, then in the last page,
committing the changes into the object and the DB.

-> This is because you have different python instances (processes) that
you lose the ability to have persisting changes accross requests in the
objects handled by an EC.


Now of course, if you can make sure that a given session is always
served by the same zeoclient, then you'll get back the "full power" of
having a session-EC, with pending (uncommitted) changes crossing the
page requests.  But I do not know if this is possible w/ zope/zeo.

  I hope I managed to be clear in my explanations. And I'll add a
paragraph making this explicit in the documentation.


-- S=E9bastien.





> Thanks,
> Paul
>=20
> On 3-Mar-06, at 18:28 , S=E9bastien Bigaret wrote:
>=20
>> Thanks for all the precisions; this is definitely a situation that
>> should be detected and handled by the product.
>>
>> I've opened ticket #1442766 for that.
>> http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1442766&g=
roup_id=3D58935&atid=3D489335
>>
>>
>> If you have some time, could you try the attached patch (replacing the
>> one 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 experience w/ zeo environments, so if you could install this
>> patch and report the observed logs for the second zeoclient, that will
>> be a great help for me to fully understand how zeo works.  In
>> particular, I'd like to determine whether TransientObject is also
>> shared and correctly setup or not --I think it is not, and, well, we'd
>> better be sure! or the second, 3rd etc. zeo instances won't have any
>> SESSION.defaultEditiingContext.
>>
>> -- S=E9bastien.
>>
>>
>> PS: LOG statements at the INFO level for the purpose of verifications
>> --they should be DEBUG or BLATHER when committed.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting lang=
uage
> that extends applications into web and mobile media. Attend the live
> webcast
> and join the prime developer group breaking into this new coding territ=
ory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Modeling-users mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/modeling-users
>=20
>=20