Add a SafeDeserializingSessionRepository

[rwinch]

I'm not sure about the name just yet, but we should have a SessionRepository implementation that can ignore specific set of exceptions to allow ignoring of deserialization exceptions (i.e. when a serialization UID changes). The implementation would look something like this, but would either allow for customizing the exceptions that are ignored or we would require updates to the existing implementations to ensure that they threw a consistent exception if deserialization failed (perfered):

public class SafeDeserializingSessionRepository<S extends ExpiringSession> implements SessionRepository<S> {
    private final SessionRepository<S> repository;

    public SafeDeserializingSessionRepository(SessionRepository<S> repository) {
        this.repository = repository;
    }

    public S getSession(String id) {
        try {
            return repository.getSession(id);
        } catch(SerializationException e) {
            delete(id);
            return null;
        }
    }

    public S createSession() {
        return repository.createSession();
    }

    public void save(S session) {
        repository.save(session);
    }

    public void delete(String id) {
        repository.delete(id);
    }
}

Relates to #280

[vpavic]

@rwinch What do you think about introducing some sort of error handling strategy to deal with this scenario? The default implementation would be no-op and user could plug-in the desired strategy into SessionRepository of their choice.

Regarding the approach you've outlined - what's your take on registering SessionRepository bean(s) with application context? IMO preferred approach would be to have a single SessionRepository in the application context, meaning only decorator instance would be registered. However, this would be an issue with some delegates since we have multiple SessionRepository implementations that use @Scheduled on their methods.

Furthermore, this decorator should probably be implementing FindByIndexNameSessionRepository, right?

[rwinch]

@vpavic Thank you for your thoughts.

To be honest I haven't completely thought this one out myself so your response is quite valuable in getting this moving forward.

What do you think about introducing some sort of error handling strategy to deal with this scenario? The default implementation would be no-op and user could plug-in the desired strategy into SessionRepository of their choice.

I like the decorator strategy because it can impact all implementations and all locations with a single piece of code.

Regarding the approach you've outlined - what's your take on registering SessionRepository bean(s) with application context? IMO preferred approach would be to have a single SessionRepository in the application context, meaning only decorator instance would be registered. However, this would be an issue with some delegates since we have multiple SessionRepository implementations that use @scheduled on their methods.

I think we would have to register both implementations, but mark one of the beans as primary. This is a bit unfortunate side effect of Java Configuration not being as flexible as XML configuration.

Furthermore, this decorator should probably be implementing FindByIndexNameSessionRepository, right?

This is a good point.

[vpavic]

@rwinch Considering #546 will introduce new strategy for fetching sessions, this serialization handling decorator is IMO better suited to be applied to this new interface. That way we'll eliminate the need to have multiple SessionRepository registered with the app context. Your thoughts on this approach?

[rwinch]

@vpavic Thanks for your feedback. It sounds as though that solution would be limited to JDBC operations? I would prefer to allow this feature to support all repository implementations.

[vpavic]

@rwinch Sorry for the noise, somehow I managed to completely disregard the fact this should apply to all repository implementations. Still fresh off the vacation I guess... 😕

So, assuming we go with the decorator implementing FindByIndexNameSessionRepository, would you just provide this implementation and let the users wrap it around the delegate themselves or should there be some support for applying it automatically?

[vpavic]

@rwinch I'll give this a look, hopefully in time to add it to 1.3.0.M3.

[vpavic]

I've proposed the solution for this in #646 - feedback is welcome.