[DISCUSS] System architecture for Red5 client session store

["seba.wagner@gmail.com" <se...@gmail.com>]

I have not yet finished my refactoring of the session store, but at least
the existing functionality is now implemented.

I would like to share some thoughts about the session store.

All implementations are done against an interfaces, so for example the
IClientList interface defines the methods needed to save, access or delete
a session.

But the "HashMapStore.java" class is no interface. It is not even a Spring
Bean. It is bundled with the "ClientListHashMapStore.java" class.
It will exist only one (static) instance of the HashMapStore.
The HashMapStore is actually a Map, but a Map with multiple keys.
Methods of the "HashMapStore" can (and should not) accessed by any class
other then the ClientListHashMapStore.
An exception is just the JUnit test that does some result verification by
accessing the Map directly.

A possible EHCache implementation could be implemented against the
IClientList interface.
However I have not yet done any research on what methods EHCache provides
to store a multi-key Map (Or if we will end up with a similar approach
using multiple lists).

The ISharedSessionStore is different from the IClientList, in that sense as
it only contains methods that are interesting for the cluster mechanism.

Sebastian
-- 
Sebastian Wagner
https://twitter.com/#!/dead_lock
http://www.webbase-design.de
http://www.wagner-sebastian.com
seba.wagner@gmail.com

Re: [DISCUSS] System architecture for Red5 client session store

[Maxim Solodovnik <so...@gmail.com>]

Maybe HashMapStore should be hidden somehow? Make it inner class with
private/package access?


On Mon, Dec 3, 2012 at 1:37 PM, seba.wagner@gmail.com <seba.wagner@gmail.com
> wrote:

> I have not yet finished my refactoring of the session store, but at least
> the existing functionality is now implemented.
>
> I would like to share some thoughts about the session store.
>
> All implementations are done against an interfaces, so for example the
> IClientList interface defines the methods needed to save, access or delete
> a session.
>
> But the "HashMapStore.java" class is no interface. It is not even a Spring
> Bean. It is bundled with the "ClientListHashMapStore.java" class.
> It will exist only one (static) instance of the HashMapStore.
> The HashMapStore is actually a Map, but a Map with multiple keys.
> Methods of the "HashMapStore" can (and should not) accessed by any class
> other then the ClientListHashMapStore.
> An exception is just the JUnit test that does some result verification by
> accessing the Map directly.
>
> A possible EHCache implementation could be implemented against the
> IClientList interface.
> However I have not yet done any research on what methods EHCache provides
> to store a multi-key Map (Or if we will end up with a similar approach
> using multiple lists).
>
> The ISharedSessionStore is different from the IClientList, in that sense as
> it only contains methods that are interesting for the cluster mechanism.
>
> Sebastian
> --
> Sebastian Wagner
> https://twitter.com/#!/dead_lock
> http://www.webbase-design.de
> http://www.wagner-sebastian.com
> seba.wagner@gmail.com
>



-- 
WBR
Maxim aka solomax