Why does MemberService issue a ReadLock of the entire MemberTree for its queries?
We noticed our Azure SQL Server CPU spiking on user login (we may have been hit with a bot, but that type load is to be expected at certain times for us). When I ran the query execution plan, it seemed fine.
Then Azure was telling us that there was locking going on. I then dug into the MemberService code, and saw the following:
public IMember GetByUsername(string username)
{
// TODO: Somewhere in here, whether at this level or the repository level, we need to add
// a caching mechanism since this method is used by all the membership providers and could be
// called quite a bit when dealing with members.
using (var scope = ScopeProvider.CreateScope(autoComplete: true))
{
scope.ReadLock(Constants.Locks.MemberTree);
var query = Query<IMember>().Where(x => x.Username.Equals(username));
return _memberRepository.Get(query).FirstOrDefault();
}
}
We are curious as to why the tree is being locked to query a user by username? Also, is there any plan to cache this? It seems like a high priority area to cache for any site that has members.
Why does MemberService issue a ReadLock of the entire MemberTree for its queries?
We noticed our Azure SQL Server CPU spiking on user login (we may have been hit with a bot, but that type load is to be expected at certain times for us). When I ran the query execution plan, it seemed fine.
Then Azure was telling us that there was locking going on. I then dug into the MemberService code, and saw the following:
We are curious as to why the tree is being locked to query a user by username? Also, is there any plan to cache this? It seems like a high priority area to cache for any site that has members.
Thanks
is working on a reply...