User Rights Storage Issues

The current design pattern is
User and role associations
Roles and menus, manipulating associations
That is, a field in a role is a heap of numeric IDs.
Because of the large-scale ERP system, the menu and operation is very
So the number of fields stored in the role is very large.

The current practice is to save the role ID session, each time the database read, and now want to put this heap of numbers into the session, look at the next 16k, afraid to save the session inside the server pressure caused too much.

There is no good solution.

Reply content:

The current design pattern is
User and role associations
Roles and menus, manipulating associations
That is, a field in a role is a heap of numeric IDs.
Because of the large-scale ERP system, the menu and operation is very
So the number of fields stored in the role is very large.

The current practice is to save the role ID session, each time the database read, and now want to put this heap of numbers into the session, look at the next 16k, afraid to save the session inside the server pressure caused too much.

There is no good solution.

Do I think the design itself has to be modified? 16k If the Java Long data can be stored 2000 is this a little bit more?

If for other reasons can not be changed, then if the role of the function ID is relatively fixed, you can consider the data cache in the application server, the session only store the user's role ID, each request come through the role ID to get the corresponding function ID list, and then the rest of the judgment can be

Consider memcached or Redis to store the session if the IO is too stressful for the server.

