How do you store large session, flash data ?

[Daniel Guryca]

Hi,

I'm used to a stateful approach from grails and other older java
frameworks but having some difficulties with all is stateless strategy
in Play.

How do you usually store large data between requests ?

It is a normal thing that you need to store large and lot of back urls
+ many other parameters in flash or session object.
But as we know we are limited only to 4kB of data (which is a pretty
small number).

It's not any difficult for me to use static HashMaps and completely
break stateless flash and session objects to a stateful but How you
would do the same think being still stateless ??

Yes Play has Cache but cache does not guarantee that data you request
are in there. How do you fight it ?

Thank you
Daniel

[Guillaume Bort]

Yes the stateless architecture is sometimes a little difficult to
achieve. But the problem is not really: "where to save my session data
?", because in a stateless architecture each request should be totally
independent of the previous ones. So when you want to improve the
overall performance of the application, yes you can use the cache. But
if the data is missing, it should not be a problem since you should
always have a way to retrieve them from the request parameters.

Perhaps you could expose a typical use case that is problematic.

> --
>
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
>

[David Marko]

The typical use case could be the shopping basket, where we need to
maintain product code+amount pairs. Typicaly the hashmap could be
used, but where to store it effectively?

David

[Ricardo Lopes]

Hi David,

It depends on what you are trying to do and the resources you have.

- You can use the cache if you have lots of RAM available or memcached
and you can afford to loose some data.

- You can use the built-in session + Flash objects + extra cookies (at
least 20 cookies of 4K per domain are supported by the browsers), that
is a lot of key-value pairs for a shopping cart :-), but remember that
the cookies are transmited on each request so don't abuse..

- You can create a table on the database (or distributed hashtable or
whatever persistant or reliable thing you have) and store your session
there.

Just ideas, it depends on what you need and what you have...

Hope it helps.

Ricardo Lopes.

2009/12/10 David Marko <dmar...@gmail.com>:

[Guillaume Bort]

Typically, I would save shopping cart data in the persistent storage.
Because I'm interested to be able to retrieve all shopping carts, even
incomplete ones, to run some data analysis.

However if you don't care about incomplete shopping cart and consider
them as transient data you can safely use the play cache. When you say
"the cache does not guarantee that data you request
are in there", that is not totally true... If you store some data in
cache with an unlimited (or large enough) TTL and you have enough
memory, then your data will always be there.

And if you ask, what happen if the cache don't have enough memory ?
Think that is exactly the same problem when you store your shopping
cart data in a Servlet session object ... If you don't have enough
memory in the JVM it will likely become problematic :)

[Daniel Guryca]

Shopping cart is pretty perfectly suitable for database store - so no
problem here.

But I see problems with hidden parameters you need to store across
requests like (urls, webflow parameters, payment tokens).

"If you store some data in cache with an unlimited (or large enough)

TTL ..." yes that's exactly what I was asking for - I'm very new to
memcached so I did not know it was possible to set it this way. Great.
One can set large expiration time and you are almost safe.

For my actual project I'm going to break this stateless model as I
know we will never need more then 1 jvm instance.

Thanks
Daniel