Hitting a dead end with Play framework

[Joe San]

A couple of days ago, I wanted to rewrite my web app that runs on a Java Web stack to a Play and Scala based solution. When I started, I knew bits and pieces of Scala, but was relatively new to Play framework. But learning it and using it was easier than the hassle that I had with Struts / JSF. I'm now in a situation wherein I have to use Http Session. I was under the impression that the Play framework handles Sessions in the same way the JEE container did (on the server side). But to my surprise (which is by the way a good programming practice from my point of view) to have the web app as stateless as possible, Play's session is just a key value pair of Strings and it controlled through the Cookie. This is a dead-end for me as my app would need to store certain Objects in the session. I have to now rethink my strategy and rewrite my api so that I can avoid storing Objects in the session and play with what Play framework says! This is kind of a weird feeling as I thought that I could be done with my app by end of next week and deploy that to heroku which now seems to be a bit impossible.

Lesson learned: Analyze end-to-end on the fitment of a certain tool or a framework before writing code.

[Bear Bibeault]

What's your beef with the cookie-based sessions? The cookies are encrypted.

[Joe San]

Bear Bibeault wrote:What's your beef with the cookie-based sessions? The cookies are encrypted.

I'm not worried about encryption. I would have wanted the ability to put any Object type into my session rather than just Strings. I now have to rethink my approach to show the data in the UI so that I can overcome with the bottleneck of storing Objects in the session.

[Bear Bibeault]

Ah. Perhaps you are over-using the session?

[Joe San]

Bear Bibeault wrote:Ah. Perhaps you are over-using the session?

May be or may not be. Would you consider putting a shopping cart information in the session? Is that a case of over-using the session? My situation is similar to that!

The Play framework suggests to use a Cache (provided in the Play API) as an alternate to using session, but at the same time, they also claim that there is no guarantee for the data to remain in the cache even though we set a time limit for that object to live in the Cache. I'm now afraid to use it.

[Ulf Dittmer]

String-only sessions seem odd indeed. Using cookies for session storage even more so. Maybe Play lets you access the HttpServletRequest object, from where you could get the HttpSession?

An alternative you could implement would be to store the data in a DB, and just put the main key into the session.

[Joe San]

Ulf Dittmer wrote:String-only sessions seem odd indeed. Using cookies for session storage even more so. Maybe Play lets you access the HttpServletRequest object, from where you could get the HttpSession?

An alternative you could implement would be to store the data in a DB, and just put the main key into the session.

The idea behind that is to have a completely stateless mechanism so that it can scale very easily. In the entire Web App that i built using Scala and the Play framework, I do not have a single class or an object that has state in it. Even the local variables in the method are finals.

I can access HttpServletRequest, but I don't want to do that. No more Java container stuff for me!

[Steve Luke]

Joe Harry wrote:May be or may not be. Would you consider putting a shopping cart information in the session? Is that a case of over-using the session? My situation is similar to that!

The Play framework suggests to use a Cache (provided in the Play API) as an alternate to using session, but at the same time, they also claim that there is no guarantee for the data to remain in the cache even though we set a time limit for that object to live in the Cache. I'm now afraid to use it.

What I think you should do is store the shopping cart information in the DB. Store an Object with the data in it in the Cache, and store a key to finding the Object in the session (the key for the shopping cart could be the user's ID if it is unique and you only allow one cart per user). The cookie gives you the key to finding the data you need, and if it isn't in the cache you load it from the DB. Also store the key in the user's database entry so if the user's session times out or he logs out or something else happens, when he comes back he still has access to his shopping cart.

[Joe San]

Steve Luke wrote:
What I think you should do is store the shopping cart information in the DB. Store an Object with the data in it in the Cache, and store a key to finding the Object in the session (the key for the shopping cart could be the user's ID if it is unique and you only allow one cart per user). The cookie gives you the key to finding the data you need, and if it isn't in the cache you load it from the DB. Also store the key in the user's database entry so if the user's session times out or he logs out or something else happens, when he comes back he still has access to his shopping cart.

Thanks for the suggestion. But the shopping cart was just one example. The actual situation that I'm dealing with is with a set of questions and its related answers. The user will go through a series of tests and he can select a test where each test has a set of questions (say 20 of them roughly). Each question has a set of answers (say 4 of them). My idea originally was to get all the questions and its associated answers as soon as the user clicks "start test", put that object into a session and update that object in the session as the user progresses through the test.

When I came to know that I cannot use the session mechanism in Play for my purpose, I thought of using the Cache API offered by Play but after reading the documentation, I don't want to trust it. So now I have to change my strategy wherein when the user clicks "start test", I only get the first question and its associated answers and present it to the user. As soon as he answers it, I collect which answer he has selected in my controller, get the next question from the database and set the selected answer number in the session as a string. I do this for all the questions until the user finishes the exam. The answers in the session are stored as comma separated values (2,3;4,2,1,3,4 and so on) where the numbers represent the answer number the user selected against each question and the first element in the comma separated value is for the first question and so on. This to me looks a bit awkward but I don't have any better ideas. Is there anything else that I could try apart from the cache and the database way?

[Joe San]

I wrote a small method that would parse the comma separated answers String, update that String. But after writing it I noticed that this is just a work around to the actual problem that I'm trying to solve. In the mean time, I had another idea is so write my own Cache mechanism that I can control. I have some ideas to do that. Let me see if I can get that working!

[Joe San]

I made decent progress towards achieving my goal of completing the Web App that I started developing using Play framework. I found decent work around to overcome with the framework limitations. I hope to finish the rest soon.

[Ulf Dittmer]

Sounds good! Please let us know which workarounds you had to put in place, and which difficulties you had to overcome. I'm sure a lot of people here would like to hear about that.

[Joe San]

Ulf Dittmer wrote:Sounds good! Please let us know which workarounds you had to put in place, and which difficulties you had to overcome. I'm sure a lot of people here would like to hear about that.

I would soon be live with the Web App. It will be a collection of sample tests, articles, e-commerce. I will definitely pen down everything that I did to build that Web App in the form of articles and will refer to them through posts from Javaranch. Thanks for all your suggestions!

[Raghavan Muthu]

This is what I would have in your place Joe Harry. Hope you remember me I came here through Ulf's flagged links.

Of course, writing your own cache mechanism might NOT cost you much and it is good for a simple requirement.

The lessons learnt is a very valuable one as we at times tend to jump into conclusions just by doing few practices on the new tools/framework. If possible, also share the link with us so that we can also play around with your "custom Play framework "

[chris webster]

I reckon we could learn plenty from your Play experience, Joe, when you have time to write it up. I don't know much about web apps and caching etc. One thought around the issue of putting objects on your session as strings: maybe use JSON? You'd still have a String containing your object, but at least the structure can be retained and it's easy to map back and forth. Or am I being stupid?