When multiple threads ask for an IP at the same time it is possible for same IP to be issued to different users. That's because allocate-find works 10 or more times faster than allocate-update. There is a chance that several allocate-finds will complete before first allocate-update makes the IP unavailable.
But the whole thing *should* be wrapped in a transactional block. See the source code to rlm_sqlippool.
If mysql doesn't respect transactional boundaries, that's another issue.
Found this: problem (not unlike here, regarding DHCP implementation): "> > > Unfortunately, the mysql docs tell me that it is not currently
possible > to modify a table and select from the same table in a
subquery.
My worry > is that by splitting the above into two queries, I'll run into issues > with concurrent clients attempting randomization at the same
time,
> getting the same randomizationID, and one or more randomizations getting > overwritten. Would putting the two queries into a transaction prevent > the selected row from being read by other clients? "
answer "> I would also re-iterate that transactions alone are not a solution to
Steve's problem. Without the proper isolation level, the data returned by subsequent select/update calls could be no better than not using transactions at all. Of course, it's possible that the default isolation level will work for this use case, but this needs to be verified."
solution :-D "> You have to use a real database for that (e.g. PostgreSQL -- where
they're supported in the form of save points) ;)"
Ivan Kalik Kalik Informatika ISP