[Opensource] Bug in DBController.stateAllowed()

[Michael Rimov]

At 03:51 AM 11/18/2003, you wrote:

>Mike,
>
>I reviewed the 5.3 code again and you're correct that the problem no longer
>exists in the 5.3 code. However, I noticed that the 5.3 code only inserts
>the
>allowedStates for groups with a match in the cache and continues to iterate
>through the remaining groups performing no apparent useful function even
>after a match is found.
>
>Wouldn't it be better return true upon finding the first match in
>allowedStated
>(Option 1) or continue iterating through the remaining groups, but also
>inserting the allowedStates for groups with no match in the cache (so that
>they can be retrieved from the cache on subsequent invocations of
>stateAllowed() instead of retrieving from the database again (Option2).


Ken,

Actually, the loop you describe is not a wasted effort.  The database has 
had to perform the SQL query and prepare the resultset.  Add to that the 
idea that most JDBC drivers transfer a "batch" of records across the 
network, and chances are you can load the rest of the security data into 
the cache without a second network round trip (and often at worst case 
scenario, one more round trip).  This way, if another user logs in that has 
a set of group memberships  that intersect the first person, you save 
yourself trips to the database.  And the LRU algorithm in the cache will 
tend to weed out unused groups in the cache.

Now, that said by way of explanation, you're correct in that if a state 
match is NOT allowed, then cached security should be set so that it is 
picked up on denied situations.  So your proposed option #2 will be the 
most efficient.

I hope this clarifies what's going on internally.

                                                 -Mike