Session Corruption?

Rails
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

On 18 Nov 2008, at 00:21, Nik B wrote:

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

On Nov 17, 7:27 pm, Frederick C. [email protected]

4

On 18 Nov 2008, at 14:38, Nik B wrote:

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

On Nov 18, 2:55 pm, Nik B [email protected] wrote:

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

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.

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.

On Nov 18, 9:49 am, Frederick C. [email protected]