Home/ Questions/Q 6674005
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T03:41:42+00:00

For every function in my service, I have a security lookup to ensure the

  • 0

For every function in my service, I have a security lookup to ensure the user has permission to access the function.

The lookup function is called like: 

SecurityCheck("Insert", "Book", Session.UserID);

The lookup table looks something like this:

        | Select All | Select Own | Insert | Update | Delete |
Book    |   true     |    true    |  false |  false |  false |
Author  |   true     |    true    |  true  |  true  |  true  |
...

The lookup table is going to end up being 30-40 rows.

I’ve read that complex objects should be not be stored in the session. Is this object generally considered too big to store in my session?

Would the extra database call on every function slow down my application significantly? Where is the appropriate place to store this table?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    30-40 rows is not that big it would be around 500-1000(if you add more stuff) bytes in memory for each user 1k for 1000 users.

    But as a general rule when you do caching you have to balance the use of memory against the speed. In this case it depends on how often those services are called and what is their response time.
    Example if you have a function that takes 1 sec and it is called 1 time/second then you can use the database version. If you do the functionality right/clean it should not affect the performance.

    If you have a function that takes 0.10 secs and is called 100 times/second than I would suggest to use the in memory cache.

    Note: the rules above only work for in memory sessions.
    – If you have a SQL session – do not put them in session – load them through normal SQL I think it should work faster than loading from DB & deserializing them.
    – If you have a session state server it would depend on how the server performs but still even in this case you might want to take them from SQL as there is still serialization that will take place

    for these 2 cases another option is to put the users rights in the application cache.

    • 0