Session Corruption?

rubyonrails-talk
1

I have a vexing problem where a request is completed and customer information is stored in session (to be deleted on successful checkout). After the request completes, any subsequent action throws a Internal Server Error 500.

This is the stack trace:

http://pastie.org/317365

Could I be storing too much information in session? It's merely an address...

Debugging sessions problems is poo.

2

I have a vexing problem where a request is completed and customer information is stored in session (to be deleted on successful checkout). After the request completes, any subsequent action throws a Internal Server Error 500.

You're storing soap objects in your session ? I'm guessing wildly but
I'd guess that what's in the session references a class that was
unloaded between the two requests, so the unmarshaling code fails
horribly (if turning config.cache_classes on makes the problem go away
then that would be a strong indication that something of that nature
is the problem). One way around this would be to only store primitive
types like arrays and hashes in the session.

Fred

3

I didn't think I was storing soap objects... here is the object that is the last think I store and retrieve from the session:

--- !ruby/object:ShippingAddress address: 123 MAIN ST attributes:   customer_address_id:   preview:   user_id:   label: attributes_cache: {}

city: ANYTOWN country: US first_name: Firstname last_name: Lastname new_record: true phone_number: 555-555-5555 residential: true state: NC zip: 55555-5555

4

I didn't think I was storing soap objects... here is the object that is the last think I store and retrieve from the session:

Well the backtrace certain showed the soap serialization stuff getting
called. if you're storing an activerecord objects you'll save yourself
trouble by just storing its attributes (or just its id if its already
saved).

Fred

5

That's the issue with (perhaps poor) design - it's a temporary object never stored on the server. It's attributes are defined merely with attr_accessor's. At the end of the checkout process the virtual attributes are stored on Authorize.NET, and the actual record attributes are just an id and a customer_address_id which is used to retrieve it on Authorize.

Seems like perhaps it has something to do with the attributes_cache... but I can't find much information on how the attributes cache works.

6

That's the issue with (perhaps poor) design - it's a temporary object never stored on the server. It's attributes are defined merely with attr_accessor's. At the end of the checkout process the virtual attributes are stored on Authorize.NET, and the actual record attributes are just an id and a customer_address_id which is used to retrieve it on Authorize.

in that case I'd store a hash of those attributes in the session

Seems like perhaps it has something to do with the attributes_cache... but I can't find much information on how the attributes cache works.

Unlikely. attributes_cache is just to do with caching attributes that are expensive to create (mostly datetimes)

Fred