Alternative Session Implementation

[Carsten Senger]

Hi all,

I had been joining the GetPaid sprint at the Plone conference in Budapest
for one day and we shortly discussed the session implementation. If I see
it correctly the problems of ticket 209 are resolved (except of broken
ZODBs maybe).
We could not come up with a completely sessionless cart implementation, I
think mainly because nobody knew the GetPaid design well enough. Anyway I
have implemented the session based approach using zope.app.session. It
consists of an ISession utility and an ISessionData local persistent
utility to store the data. This means that sessions (in our case those of
anonymous users) are written to the ZODB the portal is saved in. This can
give you performance problems, depending on the number of anonymous
shopping cart users. I don't know if there are bigger GetPaid installations.
But it should be possible replace the local persistent utility with another
implementation that does the loads/dumps dance internaly and saves the
data somewhere else.

Attached you find a patch converting the implementation and the tests to
use zope.app.session. The functional anon cart tests are failing atm, but I
did not have time to look at them nor do I know if they failed before
already.

..Carsten

[Carsten Senger]

[rafael]

> Hi all,
>
> I had been joining the GetPaid sprint at the Plone conference in Budapest
> for one day and we shortly discussed the session implementation. If I see
> it correctly the problems of ticket 209 are resolved (except of broken
> ZODBs maybe).
>

Hi,
I still get this bug triggered every 2 days. Maybe my zodb is corrupted,
but my workaround for that bug is reinstalling getpaid... I tried using
the script to fix it, but did not work...

[Matt Halstead]

Hi Carsten,

On Nov 4, 12:22 pm, Carsten Senger <sen...@rehfisch.de> wrote:
> Hi all,
>
> I had been joining the GetPaid sprint at the Plone conference in Budapest
> for one day and we shortly discussed the session implementation. If I see
> it correctly the problems of ticket 209 are resolved (except of broken
> ZODBs maybe).

I just committed the patch the michael dunstan provided - it was
previously not committed, that does seem to resolve the source of the
issue for non-broken _session storages.

> We could not come up with a completely sessionless cart implementation, I
> think mainly because nobody knew the GetPaid design well enough. Anyway I
> have implemented the session based approach using zope.app.session. It
> consists of an ISession utility and an ISessionData local persistent
> utility to store the data. This means that sessions (in our case those of
> anonymous users) are written to the ZODB the portal is saved in. This can
> give you performance problems, depending on the number of anonymous
> shopping cart users. I don't know if there are bigger GetPaid installations.
> But it should be possible replace the local persistent utility with another
> implementation that does the loads/dumps dance internaly and saves the
> data somewhere else.

Can you elaborate on why session storage needed to be reimplemented?

>
> Attached you find a patch converting the implementation and the tests to
> use zope.app.session. The functional anon cart tests are failing atm, but I
> did not have time to look at them nor do I know if they failed before
> already.

It would be great if you could create a branch with your changes and
fix the tests to work.

>
> ..Carsten
>
>  Products.PloneGetPaid.session.patch
> 13KViewDownload

cheers
Matt

[Silvio]

On Fri, Nov 13, 2009 at 8:24 AM, Matt Halstead <matt.h...@gmail.com> wrote:

> But it should be possible replace the local persistent utility with another
> implementation that does the loads/dumps dance internaly and saves the
> data somewhere else.

Can you elaborate on why session storage needed to be reimplemented?

I can help about this. I had a conversation with Carsten and other people at the sprint in Budapest. My point about issue 209 is that, even if it is now resolved, it was initially caused by a bad design decision: storing carts in a non persistent database. This decision makes anonymous customers lose their carts when Zope (or zeo in a zeo cluster) is restarted; site owners never want customers to lose their carts. And the storage of carts in the temporary zodb requires the loads/dumps dance that seems to be very error-prone and leads to hard-to-trace bugs. 

          Silvio

[Michael Dunstan]

On Fri, Nov 13, 2009 at 9:45 PM, Silvio <sil...@gmail.com> wrote:
> And the storage of carts in the
> temporary zodb requires the loads/dumps dance that seems to be very
> error-prone and leads to hard-to-trace bugs.

FWIW - independent of the functional use case in discussion here -
ZODB 3.9 has an option which can be used to prevent cross database
references from being created in the first place.
allow-implicit-cross-references. So that these kinds of bugs become
trivial to trace.

Here is patch that enables the same functionality for ZODB 3.8
http://code.google.com/p/getpaid/issues/detail?id=209#c52

--
Michael Dunstan

[Mikko Ohtamaa]

FWIW - independent of the functional use case in discussion here -
ZODB 3.9 has an option which can be used to prevent cross database
references from being created in the first place.
allow-implicit-cross-references. So that these kinds of bugs become
trivial to trace.

In the other news Plone 3 won't be running on ZODB 3.9 because ZODB has been changed too much between versions. So monkey-patch is way to go.

 

Here is patch that enables the same functionality for ZODB 3.8
http://code.google.com/p/getpaid/issues/detail?id=209#c52

--
Michael Dunstan

--
GetPaid for Plone: http://www.plonegetpaid.com (overview info) | http://code.google.com/p/getpaid (code and issue tracker)
You received this message because you are subscribed to the Google Groups "getpaid-dev" group.
To post to this group, send email to getpa...@googlegroups.com
To unsubscribe from this group, send email to getpaid-dev...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/getpaid-dev?hl=en?hl=en

--
Mikko Ohtamaa
Managing director, Red Innovation Ltd.
+358 40 743 9707
www.redinnovation.com
Every problem is solvable if you can throw enough energy drinks at it

[Matt Halstead]

On Nov 13, 9:45 pm, Silvio <silv...@gmail.com> wrote:

> On Fri, Nov 13, 2009 at 8:24 AM, Matt Halstead <matt.halst...@gmail.com>wrote:
>
>
>
> >  > But it should be possible replace the local persistent utility with
> > another
> > > implementation that does the loads/dumps dance internaly and saves the
> > > data somewhere else.
>
> > Can you elaborate on why session storage needed to be reimplemented?
>
> I can help about this. I had a conversation with Carsten and other people at
> the sprint in Budapest. My point about issue 209 is that, even if it is now
> resolved, it was initially caused by a bad design decision: storing carts in
> a non persistent database. This decision makes anonymous customers lose
> their carts when Zope (or zeo in a zeo cluster) is restarted; site owners
> never want customers to lose their carts.

I'd agree with that. They will lose their carts after the session time
out, but at least that's a constant. I have a couple of questions
about the proposed implementation:

should the session data container be configured with an explicit
pkg_id so that we can control its settings just for the shop and not
any other use of sessions?

should timeout and resolution be configurable through the web?

we should also create an upgrade step that:

1) calls register_session_data_utility( self ) from the Install.py so
people don't have to do a full product reinstall to update the session
management

2) identifies unusable carts in the _sessions persistent storage and
removes them since these will still cause problems.

If this is the direction people want to head, I'd be quite keen to see
this in action in the next few weeks. I don't mind making a test
branch if you or Carsten don't have time.