Shiro Implementing session Sharing

Session sharing: In multi-application systems, if load balancing is used, the user's request is distributed to different applications, and the session data in a application is not acquired in the B application, which brings about the sharing problem.

Assume: The user first access, connected a server, the login operation entered the system, when the user again operation, the request was forwarded to the B server, the user did not log in B, at this time the user came to the login page, which is difficult to understand and accept, which leads to the session sharing.

How does the Shiro framework implement session sharing? Shiro sharing is divided into two aspects, one is the session of the share, one is the cache share. Next, combine Redis to achieve these two aspects.

A Session sharing

Shiro provides its own session manager SessionManager, which has a property called Sessiondao it to handle all session information.

For Sessiondao,shiro also provides its own implementation, commonly used is the implementation of Ehcache. Ehcache is at the JVM level, and multiple applications produce multiple cache examples that do not share information across processes. To realize sharing, it is necessary to rewrite Sessiondao, to achieve the uniqueness of the same session information by implementing our own DAO.

Take a look at the following class diagram:

1. Inherit the abstract Sessiondao provided by Shiro, overriding methods such as Create,read,delete.

2. Considering the extensibility of the system, we abstracted a data warehousing interface and provided a way to implement Redis. If we have to replace the database to store session data in the future, we just need to extend the implementation class of a database and inject it.

Two Share of Cache

Similarly, Shiro also provides its own cache manager: CacheManager, which overrides this implementation to satisfy the shared cache.

Look at the following class diagram:

1. We only need to implement Shiro's CacheManager and cache interface. The former burst the method of acquiring the cache instance, which provides the deletion and modification of the cache instance.

2. The intermediate layer of abstraction is designed to be good, provide extensibility, and later require, simply add shirocachemanager to the implementation class.

3. The cache instance in Jedisshirocachemanager is cached by Concurrenthashmap to prevent the object from being created repeatedly.

Three Configuration

3.1 Cache Configuration

<!--redismanager-->

<bean id = "Redismanager" class = "Com.yingxinhuitong.shiro.util.RedisManager" >
<property name = "Host" value = "127.0.0.1"/>
<property name = "Port" value = "6379"/>
<property name = "expire" value = "1800"/>
<!--<property name = "Password" value= ""/>-->
<!--<property name = "Timeout" value= "0"/>-->
</bean>
<!--Shiro Cache--
<bean id = "Shriocachemanager" class = "Com.yingxinhuitong.shiro.cache.JedisShiroCacheManager" >

<property name = "Redismanager" ref = "Redismanager"/>
</bean>
<bean id = "Shirojedismanager" class = "Com.yingxinhuitong.shiro.cache.CustomShiroCacheManager" >

<property name = "Shriocachemanager" ref = "Shriocachemanager"/>
</bean>

3.2 Sessiondao Configuration

<!--session DAO--

<bean id = "Shirosessionrepository"

class = "Com.yingxinhuitong.shiro.session.JedisShiroSessionRepository" >

<property name = "Redismanager" ref = "Redismanager"/></bean>

<bean id = "Sessiondao" class = "Com.yingxinhuitong.shiro.session.CustomShiroSessionDao" ><property name = " Sessionidgenerator "ref =" Sessionidgenerator "/>

<property name = "Shirosessionrepository" ref = "Shirosessionrepository"/>

</bean>

Four Code

See also: Https://github.com/zljk0306/shiro-redis-share

Attention to old ginger talk about technology, number: Helojava, or scan the following QR code.

Shiro Implementing session Sharing