search

kapilt / getpaid

Automatically exported from code.google.com/p/getpaid
0 stars 0 forks source link

If you restart Zope logged-in users with non-empty carts won't be able to log in again #209

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Log in (or register)
2. Put something in your cart
3. Restart Zope

What is the expected output? What do you see instead?
The site won't work for pages where the cart portlet is shown and the
following traceback will appear:
...
#  Module Products.CMFPlone.ActionsTool, line 114, in listFilteredActionsFor
Module Products.CMFPlone.ActionsTool, line 83, in listActionInfos
Module Products.CMFCore.ActionInformation, line 200, in __getitem__
Module Products.CMFCore.Expression, line 48, in __call__
Module Products.PageTemplates.ZRPythonExpr, line 49, in __call__
__traceback_info__: path('object/@@getpaid_control').showManageCart()
Module PythonExpr, line 1, in <expression>
Module Products.PloneGetPaid.browser.content, line 304, in showManageCart
Module Products.PloneGetPaid.cart, line 48, in get
Module Products.PloneGetPaid.cart, line 55, in _getCartForUser
Module zope.app.container.ordered, line 133, in __len__
Module ZODB.Connection, line 761, in setstate
Module ZODB.Connection, line 801, in _setstate
Module tempstorage.TemporaryStorage, line 106, in load

Please use labels and text to provide additional information.
I guess this has to do with the temporary cart storage.

Original issue reported on code.google.com by silviot on 1 Sep 2008 at 3:38

GoogleCodeExporter commented 8 years ago 
oooouchhh....thanks for pointing this out.

Original comment by cjj.ifpe...@gmail.com on 5 Sep 2008 at 10:01

GoogleCodeExporter commented 8 years ago

Original comment by cjj.ifpe...@gmail.com on 3 Oct 2008 at 2:40

GoogleCodeExporter commented 8 years ago 
I tried it on plone 3.1.6 and i was unable to reproduce this issue. It works.
It seems related to the plone 3.0.6 version (or one of its dependencies)

Original comment by asaglio...@gmail.com on 11 Oct 2008 at 4:49

GoogleCodeExporter commented 8 years ago 
I this this problem crops up with up other plone products from time to time.  
I've
been seeing it with getpaid release 0.7.0 and Plone 3.2.1.  It makes the plone 
site
inaccessible.  On this zop instance I have 7 plones.  The one plone site with 
getpaid
exhibits this problem and disallows users from logging in.  Flushing the cache
doesn't help.

Original comment by eric.c.j...@gmail.com on 4 Mar 2009 at 5:07

GoogleCodeExporter commented 8 years ago 
Tracebackk here:
http://paste.plone.org/26729

Original comment by brian.gr...@gmail.com on 4 Mar 2009 at 5:15

GoogleCodeExporter commented 8 years ago 
The last traceback and the initial 209 traceback arrive from different places, 
but
but end up at: 'Module tempstorage.TemporaryStorage, line 106, in load'
and arise from the same conditions, and result in the same effect.

Original comment by eric.c.j...@gmail.com on 4 Mar 2009 at 8:49

GoogleCodeExporter commented 8 years ago 
I got this error also, or a variant of it. It is not preventing my user to log, 
but
it is raising a key error 'n' when I try to pack. it seems the zodb is 
corrupted.
Does anyone now an workaround for this? I need very urgent to pack my site 
again. I
though about deleting all the orders objects...

Original comment by rafaelcr...@gmail.com on 24 Mar 2009 at 4:16

Attachments:

GoogleCodeExporter commented 8 years ago 
Struck by the issue with Plone 3.2.2, I removed the user action  
getpaid_manage_cart
: now Plone is accessible but when I try to pack I obtain the traceback
2009-04-13 11:13:45 ERROR ZODB.DB packing
Traceback (most recent call last):
  File "/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/DB.py", line 624, in
pack
    self._storage.pack(t, referencesf)
  File
"/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/FileStorage/FileStorag
e.py", line
1352, in pack
    opos = p.pack()
  File
"/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/FileStorage/fspack.py"
,
line 482, in pack
    self.gc.findReachable()
  File
"/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/FileStorage/fspack.py"
,
line 228, in findReachable
    self.findReachableAtPacktime([z64])
  File
"/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/FileStorage/fspack.py"
,
line 304, in findReachableAtPacktime
    todo.extend(self.findrefs(pos))
  File
"/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/FileStorage/fspack.py"
,
line 377, in findrefs
    return referencesf(self._file.read(dh.plen))
  File "/home/dan/Plone0/Zope-2.10.7-final-py2.4/lib/python/ZODB/serialize.py", line
645, in referencesf
    oid = oid_loaders[reference_type](*args)
KeyError: 'm'
2009-04-13 11:13:45 ERROR Zope.SiteErrorLog
http://127.0.0.1:8080/Control_Panel/Database/main/manage_pack
Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module <string>, line 3, in _facade
  Module AccessControl.requestmethod, line 64, in _curried
  Module App.ApplicationManager, line 431, in manage_pack
  Module ZODB.DB, line 624, in pack
  Module ZODB.FileStorage.FileStorage, line 1352, in pack
  Module ZODB.FileStorage.fspack, line 482, in pack
  Module ZODB.FileStorage.fspack, line 228, in findReachable
  Module ZODB.FileStorage.fspack, line 304, in findReachableAtPacktime
  Module ZODB.FileStorage.fspack, line 377, in findrefs
  Module ZODB.serialize, line 645, in referencesf
KeyError: 'm'

Original comment by danielle...@gmail.com on 13 Apr 2009 at 9:16

GoogleCodeExporter commented 8 years ago 
I try http://127.0.0.1:8080/Plone/portal_catalog/manage_catalogFoundItems but
 2009-04-13 11:32:54 ERROR Zope.SiteErrorLog
http://127.0.0.1:8080/Plone/portal_catalog/manage_catalogFoundItems
Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.ZCatalog.ZCatalog, line 349, in manage_catalogFoundItems
  Module Products.ZCatalog.ZCatalog, line 813, in ZopeFindAndApply
  Module Products.ZCatalog.ZCatalog, line 801, in ZopeFindAndApply
  Module Products.CMFPlone.CatalogTool, line 385, in catalog_object
  Module Products.ZCatalog.ZCatalog, line 536, in catalog_object
  Module Products.ZCatalog.Catalog, line 339, in catalogObject
  Module Products.ZCatalog.Catalog, line 277, in updateMetadata
  Module Products.ZCatalog.Catalog, line 416, in recordify
  Module Products.CMFPlone.CatalogTool, line 110, in __getattr__
  Module Products.CMFPlone.CatalogTool, line 318, in getIcon
TypeError: getIcon() takes exactly 1 argument (2 given)

but  I after have reinstalled PloneGetpaid in quickinstaller I could pack and 
export
the whole site (before I could only export objects of the site)

Original comment by danielle...@gmail.com on 13 Apr 2009 at 10:11

GoogleCodeExporter commented 8 years ago 
no more TypeError getIcon()...
with the solution proposed on http://dev.plone.org/plone/ticket/8235
a change in CMFPlone/CatalogTool.py is needed too:

def getIcon(obj, **kwargs):

    """Make sure we index icon relative to portal"""

- return obj.getIcon(True)
+ return obj.getIcon(relative_to_portal=True)
it is dated from 06/16/08 19:33:49 but it is not in Plone 3.2.2

Original comment by danielle...@gmail.com on 13 Apr 2009 at 4:45

GoogleCodeExporter commented 8 years ago 
Similar error when adding some item to cart.

Traceback (innermost last):
  Module ZPublisher.Publish, line 125, in publish
  Module Zope2.App.startup, line 238, in commit
  Module transaction._manager, line 96, in commit
  Module transaction._transaction, line 395, in commit
  Module transaction._transaction, line 503, in _commitResources
  Module ZODB.Connection, line 708, in tpc_finish
  Module ZODB.BaseStorage, line 276, in tpc_finish
  Module tempstorage.TemporaryStorage, line 229, in _finish
  Module ZODB.serialize, line 645, in referencesf
KeyError: 'n'

Original comment by taito.ho...@gmail.com on 22 Apr 2009 at 2:15

GoogleCodeExporter commented 8 years ago 
which version of Plone ?  I was struck by this problem, I've just changed 
getIcon.
Today I can see that there are no more getIcon in the CatalogTool.py of the 
trunk.
CatalogTool seems to have undergone a lot of changes 
"Make sure we use our own indexer " they said
http://dev.plone.org/plone/browser/Plone/trunk/Products/CMFPlone/CatalogTool.py?
rev=26350

but I'm not uptodate

Original comment by danielle...@gmail.com on 22 Apr 2009 at 4:01

GoogleCodeExporter commented 8 years ago 
Hi, I tried danielle fix and I didn't get the getIcon error anymore. But I am 
still
getting the key error that prevents me for packing. I am not 100% sure if this 
only
happens when I restart the site with a logged user with non empty chart.. But 
every
day or so I have to restore a backup and improt my recent changes :(

Original comment by rafaelcr...@gmail.com on 8 May 2009 at 12:30

GoogleCodeExporter commented 8 years ago 
reinstall with portal_quickinstaller empty the carts, if it comes from non empty
carts, it may be quicker

Original comment by danielle...@gmail.com on 8 May 2009 at 4:55

GoogleCodeExporter commented 8 years ago 
Can we change this issue's priority to 'critical' and status to something other 
than
'New'?  It's not new any more, and has been confirmed by many.  It breaks an 
entire
plone site, as well as a whole zope instance's ability to pack the database.  I 
think
it's as critical as a getpaid issue can get.

Original comment by eric.c.j...@gmail.com on 8 May 2009 at 5:01

GoogleCodeExporter commented 8 years ago 
I totally agree. This is driving me crazy. I have this bug even when I don't 
restart
the zeoserver... It seems it is trigged randomly when someone buy somehing...
Maybe this is related to payment processor

Original comment by rafaelcr...@gmail.com on 13 May 2009 at 7:20

GoogleCodeExporter commented 8 years ago 
Hi, Can anyone reproduce this bug without getpaid.paypal or getpaid.pagseguro? 
Someone mentioned on the list that maybe this may be related to the way the 
payment
processor deletes the cart after the processor button is pressed...
I am going to try some steps to reproduce it with a fresh Data.fs.

Original comment by rafaelcr...@gmail.com on 18 May 2009 at 3:27

GoogleCodeExporter commented 8 years ago 
Yes, we've reproduced this issue with googlecheckout as well as paypal.

Original comment by eric.c.j...@gmail.com on 18 May 2009 at 7:08

GoogleCodeExporter commented 8 years ago 
Has anyone reproduced this with authorize.net or ogone? In google checkout does 
the 
cart gets destroyed after the checkout button is pressed? I am referencing to an
email in the list gested that maybe the error is caused tdue to the way the 
cart is
destroyed...

Original comment by rafaelcr...@gmail.com on 26 May 2009 at 4:11

GoogleCodeExporter commented 8 years ago 
I am thinking about deactivating the return function, as the payment processor 
keeps
a track with what has been bought and the client's adress, reducing getpaid 
only to
the chart and sending the form... This bug is driving me crazy and restoring the
backups has consumed more time then developing the payment processor :(

I have no clue on what to do... +1 to move this to critical...

Original comment by rafaelcr...@gmail.com on 9 Jun 2009 at 12:18

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Moving to critical...

Original comment by rafaelcr...@gmail.com on 10 Jun 2009 at 7:37

GoogleCodeExporter commented 8 years ago 
PloneGetPaid seems to have some custom persistency code here:

http://code.google.com/p/getpaid/source/browse/getpaid.core/trunk/src/getpaid/co
re/options.py

It is extensively used in order/cart. Order has sections which are mapped to
PersistentBag objects which hold fields based on IOrder schema.

Original comment by mioht...@gmail.com on 29 Jun 2009 at 1:53

GoogleCodeExporter commented 8 years ago 
Does this happen 

1) With ZEO

2) Without ZEO

The problem might be that IPN call is server-to-server call and it bypasses 
normal
ZEO cookie -> session handling.

Does ZEO attach a certain user to a certain client? If IPN call hits "wrong" 
client
(not the client the user made the purchase) the cache might be different, 
causing the
problem. However this is just speculation because I don't know how ZEO works.

Original comment by mioht...@gmail.com on 29 Jun 2009 at 1:55

GoogleCodeExporter commented 8 years ago 
 use ZEO here.. But I disabled in my payment processor page the return functionality
(IPN). Meaning that I am only using the product to generate the form and send 
it...
So I think the error occurs during the checkoput process...

Original comment by rafaelcr...@gmail.com on 29 Jun 2009 at 2:00

GoogleCodeExporter commented 8 years ago 
I sent an email to zodb-dev

I received the following answer:

Your application is creating cross-database references. The version of  
ZODB you're using on the ZEO server doesn't support packing databases  
with cross References. Upgrade your ZEO server to ZODB 3.8.1 or ZODB  
3.9.

Jim

Moo-__- sugestions in #getpaid :
 i suggest the following actions 1) comment plonegetpaid bug and include link to the
email response 2) ask plone-users list whether it is a sane idea trying to use 
newer ZODB
in the most extreme case 1) we can make sure that plonegetpaid won't be using
"cross-database references" 2) backport ZODB feature

Original comment by rafaelcr...@gmail.com on 29 Jun 2009 at 4:17

GoogleCodeExporter commented 8 years ago 
Upgrading zodb to 3.8.1 allowed me to pack again. Is this a final solution?

[versions]
ZODB3 = 3.8.1
zope.proxy = 3.5.0

Original comment by rafaelcr...@gmail.com on 29 Jun 2009 at 4:40

GoogleCodeExporter commented 8 years ago 
Another email from zodb list:

Cross-database references are presumably created if something in the  
session references a persistent item from the main ZODB, or vice  
versa.  Those references would then get broken if Zope restarts  
(clearing the session from RAM) or if one of the databases is packed  
(since the ZODB doesn't support multi-database garbage collection, at  
least not until the separate package Jim made recently for that  
purpose).

You'll have to figure out where in GetPaid these references are  
getting created, and stop doing that.

David

Original comment by rafaelcr...@gmail.com on 29 Jun 2009 at 4:41

GoogleCodeExporter commented 8 years ago 
Zope has temporary storage database (for sessions) and permanent storage 
(FileStorage).

ZODB 3.0 can't handle cross-database references. Permanent storage might get
reference to a temporary storage object (tied to session) in some point of 
checkout.

I suspect this is some reference from order to cart or its child objects.

As said earlier somewhere this might have something to do in the way the cart is
destructed.

Upgrading ZODB to 3.8 does not actually fix the bug, but causes the ZODB handle 
the
situation more graceful. Dangling pointers don't seem to cause exceptions 
anymore.

Original comment by mioht...@gmail.com on 30 Jun 2009 at 8:46

GoogleCodeExporter commented 8 years ago 
There seems to be some hack loads(dumps(cart)) to "clear" it somehow, but I 
assume it
is not working. See Products.PloneGetPaid.browser.checkout.CheckoutReviewAndPay 
class.

Original comment by mioht...@gmail.com on 30 Jun 2009 at 8:50

GoogleCodeExporter commented 8 years ago 
Or it might be the reverse situation. Where that dumps&loads dance for the cart 
has
been missed out in some place.

(Though I agree that the dumps&loads dance looks funky and should be reviewed.)

Original comment by michael....@gmail.com on 30 Jun 2009 at 9:44

GoogleCodeExporter commented 8 years ago 
To soon to celebrate.. With zodb 3.8.1 I can pack, but now am getting this error
trying to acces an cart. Traceback attached...

Original comment by rafaelcr...@gmail.com on 30 Jun 2009 at 12:55

Attachments:

GoogleCodeExporter commented 8 years ago 
I've managed to recreate the problem with the following steps:

- Checkout the getpaid trunk.

- Run buildout -c 316.cfg

- Start Zope.

- Log in to Zope and add a Plone site.

- Use the Plone site setup to install "PloneGetPaid 0.7.9".

- Go to the getpaid configuration panel make page buyable. Every other setting 
can be
left as the default. Including the payment processor.

- Go to the site front page and make that buyable and activate. Should now see 
the
getpaid portlet on the front page.

- Log out from Plone.

- Go to the home page.

- Click on add to cart. You should now see 1 item in your cart. And you should 
still
be logged out.

- Click on checkout. That will prompt you for a login.

- Login. That will take you to the checkout out page.

- Restart Zope.

Now we have broken references and lots of errors will start showing up.
The simplest example for testing is to:

- Refresh the current page in the browser for @@getpaid-checkout-wizard. That'll
generate the following tracebacks in zope event log:

2009-07-01 10:21:43 ERROR ZODB.Connection Couldn't load state for 0x30
Traceback (most recent call last):
  File "/opt/sites/getpaid/trunk/parts/zope2/lib/python/ZODB/Connection.py", line
761, in setstate
    self._setstate(obj)
  File "/opt/sites/getpaid/trunk/parts/zope2/lib/python/ZODB/Connection.py", line
801, in _setstate
    p, serial = self._storage.load(obj._p_oid, self._version)
  File
"/opt/sites/getpaid/trunk/parts/zope2/lib/python/tempstorage/TemporaryStorage.py
",
line 106, in load
    s=self._index[oid]
KeyError: '\x00\x00\x00\x00\x00\x00\x000'
2009-07-01 10:21:43 ERROR Zope.SiteErrorLog
http://localhost:8080/plone/@@getpaid-checkout-wizard
Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module Products.PloneGetPaid.browser.checkout, line 335, in __call__
  Module Products.PloneGetPaid.browser.checkout, line 259, in checkShoppingCart
  Module zope.app.container.ordered, line 133, in __len__
  Module ZODB.Connection, line 761, in setstate
  Module ZODB.Connection, line 801, in _setstate
  Module tempstorage.TemporaryStorage, line 106, in load
KeyError: '\x00\x00\x00\x00\x00\x00\x000'

I could not recreate the error if the shopper was already logged in before 
adding
items to the cart.

Original comment by michael....@gmail.com on 30 Jun 2009 at 10:37

GoogleCodeExporter commented 8 years ago 
Anonymous cart is stored in session in Products.PloneGetPaid.cart:

    def _getCartForSession(self, context, create=False, browser_id=None):
        session_manager = getToolByName(context, 'session_data_manager')
        if browser_id is None:
            if not session_manager.hasSessionData() and not create:
                return
            session = session_manager.getSessionData()
        else:
            session = session_manager.getSessionDataByKey(browser_id)
            if session is None:
                return
        if not session.has_key('getpaid.cart'):
            if create:
                session['getpaid.cart'] = cart = ShoppingCart()
            else:
                return None
        return session['getpaid.cart']

I assume session data goes to TemporaryStorage.

It is cleared when the site is restarted.

However _getCartForSession does not return None. I think session data manager 
only partially clears the session. It returns some broken object instead of 
None. You 
might want to investigate what kind of object is returned by      
session['getpaid.cart'] in the error situation.

Original comment by mioht...@gmail.com on 1 Jul 2009 at 9:59

GoogleCodeExporter commented 8 years ago 
Also check what session (session_manager.getSessionData()) has eaten.

You can do this by putting in pdb breakpoint in the code and inspect the data 
from the 
debugger.

Original comment by mioht...@gmail.com on 1 Jul 2009 at 10:01

GoogleCodeExporter commented 8 years ago 
Looks like the dumps&loads dance may do the right thing.

I have found a place in the code where that the cart is directly referenced 
from the
main storage back to the temporary (session) storage. There is no attempt to 
copy or
de reference the cart.

See the attached patch. This at least seems to fix the problem as detailed in 
comment
33 above.

Original comment by michael....@gmail.com on 1 Jul 2009 at 1:01

Attachments:

GoogleCodeExporter commented 8 years ago 
Maybe the Cart class itself should contain a method getSafeCartCopy() (doing 
internally 
dumps loads dance)?

Original comment by mioht...@gmail.com on 1 Jul 2009 at 1:45

GoogleCodeExporter commented 8 years ago 
 It seems the patch has done the trick. I restarted here and did not get the error. I
will hjowever wait 1 day more to be 100% sure, cause not everytime I restarted 
I got
it... Thank you very much...

Original comment by rafaelcr...@gmail.com on 1 Jul 2009 at 2:06

GoogleCodeExporter commented 8 years ago 
Ok, 24 hours without this error. It seems Michael solve it... Prevents the bug 
from
happening (not fix already corrupted zodb).  Two magic lines... 

I don't know why, but I forgot to copy the import cpickle line and it still 
works. If
someone can confirm this...

Original comment by rafaelcr...@gmail.com on 2 Jul 2009 at 3:37

GoogleCodeExporter commented 8 years ago 
I think missing out the import could resolve the problem in a sense... But the
shopper would not be able to complete the process. Instead they will see an 
error.
Meanwhile that error will leave the storage intact.

Check your error logs to see if there are any.

Note that this patch relates to the steps outlined in Comment 33. The error is 
only
tripped when a shopper starts adding items to their cart when they are logged 
out
then visits the checkout and is prompted to login. Soon as they login the error 
is
tripped.

Original comment by michael....@gmail.com on 2 Jul 2009 at 10:16

GoogleCodeExporter commented 8 years ago 
Bad news... The error returned.

I just added the import line, but could find nothing in my logs complaining 
about it...

I am using anonymous checkout, so my error is not exactly the same as in comment
33... But it occurs sometimes after the server is restarted... Before I moved 
from
ZEO to filestorage it occured even without restarting it...

My traceback whenb trying to add an item to the cart:

Traceback (innermost last):

    * Module ZPublisher.Publish, line 119, in publish
    * Module ZPublisher.mapply, line 88, in mapply
    * Module ZPublisher.Publish, line 42, in call_object
    * Module Products.PloneGetPaid.browser.cart, line 74, in __call__
    * Module Products.PloneGetPaid.browser.cart, line 82, in addToCart
    * Module Products.PloneGetPaid.content, line 60, in create
    * Module Products.PloneGetPaid.content, line 181, in createLineItem
    * Module five.intid.intid, line 33, in register
    * Module ZODB.Connection, line 811, in setstate
    * Module ZODB.Connection, line 870, in _setstate
    * Module ZODB.serialize, line 604, in setGhostState
    * Module ZODB.serialize, line 597, in getState
    * Module ZODB.serialize, line 479, in _persistent_load
    * Module ZODB.serialize, line 543, in load_multi_oid
    * Module ZODB.serialize, line 537, in load_oid
    * Module ZODB.Connection, line 244, in get
    * Module tempstorage.TemporaryStorage, line 108, in load

KeyError: '\x00\x00\x00\x00\x00\x00\x00\x88'

Original comment by jovemcom...@gmail.com on 3 Jul 2009 at 2:07

GoogleCodeExporter commented 8 years ago 
The only mention to getpaid in my logs I found was this error I don't know what 
means..

Original comment by jovemcom...@gmail.com on 3 Jul 2009 at 2:16

Attachments:

GoogleCodeExporter commented 8 years ago 
jovemcomunista: that's you rafaelcrocha?

Looks like a useful debugging step would be to use ZODB 3.9.0b2 and configure:

   allow-implicit-cross-references

to false. Then you should get an error much closer to the source of the problem.

Original comment by michael....@gmail.com on 4 Jul 2009 at 4:35

GoogleCodeExporter commented 8 years ago 
Found that there are a couple of bare excepts in the code base. It might be a 
miss
handled ConflictError that is causing this other problem. Attached is a patch 
that
lets ConflictError's through. And adds a bit of logging while doing so to help
identify this as a cause or not.

Original comment by michael....@gmail.com on 5 Jul 2009 at 6:37

Attachments:

GoogleCodeExporter commented 8 years ago 
hi folks,

the problem isn't the load ( dumps( )) that's actually the correct way to *not*
create a cross database reference when moving an object between storages.

unfortunately i've been away from the codebase long enough, that i have no idea
what's been commmitted in the interim that might be trying to move objects from
sessions to persistent zodb.

are you guys using persistent shopping carts?

Original comment by kapil.f...@gmail.com on 6 Jul 2009 at 9:41

GoogleCodeExporter commented 8 years ago 
the only sane thing might be auditing all uses of the session variables.

Original comment by kapil.f...@gmail.com on 6 Jul 2009 at 9:43

GoogleCodeExporter commented 8 years ago 
Kapil: yeah - that's what the patch in comment #36 does. It uses the 
load(dumps())
dance to resolve the original reported problem.

Original comment by michael....@gmail.com on 6 Jul 2009 at 10:40

GoogleCodeExporter commented 8 years ago 
Hi michael. it was me writing as jovemcomunista. A friend of mine forgot to log 
off
and I posted with his username...

After I added the forgotten import line I did not get the error for 3 days 
already.
So maybe the patch fixed it after all. I would like to hear from others who were
experiencing it..

Thanks,
Rafael

Rafael

Original comment by rafaelcr...@gmail.com on 7 Jul 2009 at 2:28

GoogleCodeExporter commented 8 years ago 
Hi,
I was just going to write here that this path definatevly fixed my issue, but I 
got
the error again.I am applying the patch from comment 44 to see if we can get 
more
info about it... Attached my last traceback...
Thanks

Original comment by leonelgo...@gmail.com on 12 Jul 2009 at 10:58

Attachments:

GoogleCodeExporter commented 8 years ago 
leonelgo...

Going by that traceback it looks like you are using some kind of shipping:
Products.PloneGetPaid.content, line 181, in createLineItem

What shipping methods are you using?

Original comment by michael....@gmail.com on 13 Jul 2009 at 2:00