So it sounds like the thing you're doing that's unusual is to store objects as JSON in a denormalized sessions table instead of normalized database tables. That can be good for some things. In general, I don't recommend it. Here are some reasons why:

• Databases work hard to provide a sane model for concurrent access. You break that by using denormalized storage. It's usually ok if the cached objects are all related to a single user or read-only, but the chances for lost updates and other problems become high for shared read/write data. They can also get stale and miss updates in the underlying tables.
• Serialized perl objects aren't easy to search. If you have no normalized storage of your shopping cart and you want to find all the carts that contain seminar 75, you have to walk through all carts in the system.
• One reason that people often design from the database up is because the database is nearly always the bottleneck and the schema design has the largest affect on your application's scalability and performance. Trying to hide or bypass the database tables can lead to designs that don't take advantage of the details of your database's implementation.
• Large sessions often perform badly. They can easily end up needing to serialize/deserialize lots of objects that aren't even used by the current request.

I don't mean to rain on your parade. Just pointing out some messes I've made before with sessions and caching of database objects. Apologies if I've misunderstood what you're doing.