[Serdev] Group membership functions

[Jan Janak]

Hello,

I have personally never tried it with MySQL 4, but I don't expect any
problems :-).

Could you, perhaps, test it and let me know if it works or not ?

  thanks, Jan.

On 24-07 11:52, Gulherme Dal Pizzol wrote:
> I was looking at MySQL site (www.mysql.com) and noticed that MySQL 4 has a
> "query cache". In this way, a database caching mechanism at SER would not
> be necessary (only in the case that you need really maximum performance,
> as Jan said).
> 
> But, is SER compatible with MySQL 4? Has anyone tested it?
> 
> Thanks again,
> 
> Guilherme.
> 
> > On 24-07 08:31, Jiri Kuthan wrote:
> >> At 12:23 AM 7/24/2003, Gulherme Dal Pizzol wrote:
> >> >Hello all,
> >> >
> >> >I was looking at the group membership checking functions and noticed
> >> that it always make an access to the MySQL database. This could be
> >> too slow if the function "is_user_in" is used frequently, right?
> >>
> >> Yes, they potentialy could. We haven't measured the real impact but it
> >> is a potential bottleneck.
> >>
> >> >(mysql always access the disk, there is no cache)
> >> >So, I was wondering if these functions could use shared memory tables
> >> (along with mysql tables) to speedup the access to the group
> >> information, just like in ursloc/registrar modules.
> >>
> >> Yes, they could. It is on our long-term list of things which would be
> >> nice  to have. I don't think though that the problem in existing
> >> deployments  was stressing us to prioritize it now.
> >>
> >> >If it is possible, should I try to extend usrloc/group module or
> >> implement shared memory tables directly in group module?
> >>
> >> Reasonable contributions are always welcome. I think what it really
> >> takes is some generic database-caching mechanism you could use to
> >> groups,  authentication database and whatsoever.
> >
> >   I wouldn't proceed with a general caching mechanism here, caching can
> > be highly optimized for a specific task and that will be faster.
> >
> >   As Jiri said, we welcome such contributions, if the code is good then
> > we will include into the main tree. Let me know if you have any
> >   questions or problems (write to this mailing list).
> >
> >     Jan.
> 
> 
>