Re: Overwhelming a Web Application Server

Nathan Andelin skrev:

From: Walden H. Leverich
Why? Because of the "if all goes well" comment?

Well, yes actually. I honestly thought that Thorbjoern was making a joke - no offense intended.

Actually it was a bit tongue-in-cheek :-)

Serialization is not easily done _correctly_ and the usual problem is exactly when you change a class as it requires great care to ensure that the new class deserializes correctly from the byte stream produced by serializing the old class. It is somewhat similar to ensuring that SQL statements work correctly even if you change the database schemas...

I guess that's an OO thing. My perspective was more in line with Brad Stone's idea of storing session data in a DB record, keyed by session ID. The session ID is stored in a cookie that goes back and forth between a browser and server. Use the key to fetch a DB record to restore session data. In that context the "if all goes well" comment sounded hilarious. RPG programmers don't think twice about "chaining" to a record, and hardly concern themselves about it's reliability or performance.

The analogy would be that you add columns to your session data table, and need to think of what happens when old users come back and load in their incomplete session data :)

Remember, you may be deserializing the object many hours
later, one of our applications run session times around 24 hours.

I admit that I don't understand much about OO deserialization.

Lets say you have a shopping cart - a list of items - each item has a barcode and a quantity. This is usually modelled with a Cart object having a list of Items where an item has a barcode (probably a string) plus a quantity (probably an integer).

Serialization means something like "hey, JVM, give me an array of bytes representing this Cart thing", and deserialization means something like "hey, JVM; I have these bytes, gimme what they mean" - "Sure, here is a Cart object".

It is the original way that JVM's could talk together and is pretty nifty :)

We have many users that leave there browsers up overnight and
expect to still run in the same session the next day.

Now that's something I can relate to. You definitely want to keep users happy, and I know that in a lot of cases they expect their web applications to behave like desktop applications. In some cases, you don't want sessions to expire, or be "serialized".

You always have to make a trade-off. If you keep everything in memory, you WILL run out eventually (if not earlier, then when it gets popular enough, and THEN we have the 3 AM wakeup call).

Here the trick is degrading gracefully so you still service everybody and make the sale. This is unfortunately hard :(