Handing out duplicate IP addresses

[tnt at kalik.net]

>> 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