Handing out duplicate IP addresses
tnt at kalik.net
tnt at kalik.net
Mon Jan 19 15:36:08 CET 2009
>> 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.
problem (not unlike here, regarding DHCP implementation):
"> > > Unfortunately, the mysql docs tell me that it is not
> > possible
> > > to modify a table and select from the same table in a
> > My worry
> > > is that by splitting the above into two queries, I'll run into
> > issues
> > > with concurrent clients attempting randomization at the same
> > > 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?
"> 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
"> You have to use a real database for that (e.g. PostgreSQL -- where
> they're supported in the form of save points) ;)"
Kalik Informatika ISP
More information about the Freeradius-Users