-
Defect
-
Resolution: Done
-
Minor
-
None
-
None
From my basic understanding, every time that a User is requested from the RuntimeUserService the User is looked up by Username (or some other mechanism) which makes a call to hibernate. I understand that the User instance is most likely cached, but this still doesn't seem proper.
I noticed this behavior tracking down a speed issue involved with authorizing a User to access ~1860 File Access Points. Every time there was a call to security there was eventually a call that would get the User from the Database. (A Error Use Case can be produced if needed.)
From what I've learned it is best to have a filter that will get the User for that request, place the User on the the ThreadLocal somewhere and then that User Instance is used for the entire request. The User can also be placed into the HttpServletRequest so that things like JSPs and Tags can have quick access to the User instance if they need it.
There are other ways for doing this as well, but at least storing the User per Request would be beneficial.
I noticed this behavior tracking down a speed issue involved with authorizing a User to access ~1860 File Access Points. Every time there was a call to security there was eventually a call that would get the User from the Database. (A Error Use Case can be produced if needed.)
From what I've learned it is best to have a filter that will get the User for that request, place the User on the the ThreadLocal somewhere and then that User Instance is used for the entire request. The User can also be placed into the HttpServletRequest so that things like JSPs and Tags can have quick access to the User instance if they need it.
There are other ways for doing this as well, but at least storing the User per Request would be beneficial.