Improve session support to be more friendly to persistent and expensive stores.

[ldaley]

What is currently SessionStorage should become:

public interface SessionStorage {

  // Returned object is not live, is a copy of the data at read time
  <T extends Serializable> Promise<Optional<T>> get(TypeToken<T> type);

  <T extends Serializable> Promise<Boolean> put(TypeToken<T> type, T t);

  <T extends Serializable> Promise<Integer> remove(TypeToken<T> type);

  Promise<Optional<String>> get(String key);

  Promise<Boolean> set(String key, String value);

  Promise<Integer> remove(String key);

  Promise<Integer> clear();

}

1. Reads from the session always return value objects (i.e. changes to the objects are not automatically written back to the session)
2. Type based storage is based on equality, not assignability

[wmacgyver]

@alkemist you want this to lead to ratpack-hazelcast in the end, any particular reason on hazelcast vs say redis? Don't get me wrong, I use and love hazelcast. I'm just curious if there was a reason. Is it because it's very easy to integrate on JVM?

[ldaley]

@wmacgyver I do want both.

That is, the idea is that you can drop in different impls.

[davidmc24]

Do we want to add support for other session-related capabilities as part of this? Invalidate, get/set timeout, start time, last access time?

Link to equivalent shiro interface:
http://shiro.apache.org/static/1.2.1/apidocs/org/apache/shiro/session/Session.html

[wmacgyver]

wow, feature creep already :)

[ldaley]

@davidmc24 I'd say a lot of that makes sense to include.

[beckje01]

For a first cut I landed on the following:

public interface SessionStorage  {

  <T> Promise<Optional<T>> get(String key, Class<T> type);

  Promise<Boolean> set(String key, Object value);

  Promise<Set<String>> getKeys();

  Promise<Integer> remove(String key);

  Promise<Integer> clear();
}

This will allow expensive stores but didn't get into the Type based storage.

[wmacgyver]

shouldn't invalid/timeout be part of the interface too?

[ldaley]

@wmacgyver can you elaborate?

[beckje01]

Invalidate and timeout are part of the session itself not the storage inside a session. We currently have these split. So you can invalidate and time out sessions without ever using a session storage.

[wmacgyver]

@alkemist @beckje01 my bad, I didn't realize it's split this way.

[beckje01]

@wmacgyver Its confusing look for some docs soon...

[ldaley]

It's also not set in stone. We may in fact merge these two things.

[gschrader]

This is a bit of a breaking change and it wasn't obvious at first why. The promise needs to be acted on for the SessionStorage methods to do anything.

this code:

        get("logout") { SessionStorage sessionStorage ->
            sessionStorage.clear()
            redirect("/")
        }

now needs to be:

        get("logout") { SessionStorage sessionStorage ->
            sessionStorage.clear().then({})
            redirect("/")
        }

I'm not sure if there is a cleaner way to handle this.

[ldaley]

It actually needs to be:

        get("logout") { SessionStorage sessionStorage ->
            sessionStorage.clear().then { redirect "/" }
        }

Otherwise, you are issuing the redirect and then clearing the session.

Re not subscribing to the session, we are working on some diagnostics that would have helped to point this out.

[gschrader]

Ah cool yes that makes sense now, thanks!