# Session Corruption? **URL:** \ **Category:** Rails\ **Created:** [November 18, 2008, 1:22am UTC](https://www.ruby-forum.com/t/session-corruption/153496 "2008-11-18T01:22:54Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 1:22am UTC](https://www.ruby-forum.com/t/session-corruption/153496/1 "2008-11-18T01:22:54Z")
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](http://pastie.org/317365) Could I be storing too much information in session? It’s merely an address… Debugging sessions problems is poo. ---
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 1:28am UTC](https://www.ruby-forum.com/t/session-corruption/153496/2 "2008-11-18T01:28:10Z")
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 ---
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 3:39pm UTC](https://www.ruby-forum.com/t/session-corruption/153496/3 "2008-11-18T15:39:19Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 3:49pm UTC](https://www.ruby-forum.com/t/session-corruption/153496/4 "2008-11-18T15:49:54Z")
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 ---
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 5:02pm UTC](https://www.ruby-forum.com/t/session-corruption/153496/5 "2008-11-18T17:02:09Z")
On Nov 18, 2:55 pm, Nik B [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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](http://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 ---
**Author:** ![Nik\_B](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/ee59a6/32.png) [@Nik\_B](https://www.ruby-forum.com/u/Nik_B)\ **Post date:** [November 18, 2008, 3:56pm UTC](https://www.ruby-forum.com/t/session-corruption/153496/6 "2008-11-18T15:56:22Z")
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](http://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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)