This is my Blog.

It's full of opinions on a wide range of stuff.

Meet Lift’s ContainerVar

For those of you who have been following or working with Lift for sometime, you will know that our implementation of sessions provides a strongly-typed variable holder, but had a limitation in that it was not serializable across application servers using familiar scaling technologies like Terracotta. This is completely fine for the vast majority of use cases and having the extra type-safety and flexibility that SessionVar brings is valuable.

However, there are situations and organizations that require scaling via their existing Java infrastructure and up until now Lift was unable to service that. Well, that is no longer the case as Lift has a new variable buddy called ContainerVar to sit alongside RequestVar, SessionVar and TransientRequestVar.

What's the bobby?

Firstly, its important to understand that ContainerVar is not a replacement in any way-shape-or-form for SessionVar. It is an accompaniment to provide people who want to use a session store that is backed by the container. This does however come with several limitations in that you are then restricted to storing session data in strings, ints and so on that are moderately basic types which are serializable.

How's it work?

Glad you asked.

object MySnippetCompanion {
  object mySessionVar extends ContainerVar[String]("hello")

As you can see, this is just like the other state variables within Lift. All the plumbing is abstracted away from you, so all you need to do is ensure your container sessions are configured correctly.

I was hoping to make a sample application using "HazzleCast": or Terracotta but alas I need to get on with writing "Lift in Action": so you good reader can learn more about the deep workings of Lift.

blog comments powered by Disqus