A lock shouldn't survive a reboot, AFAIK. The original install was on a
Quad PII-400 Xeon box, and I do remember seeing the CPU spike problem,
even though RadiusNT was not installed on the machine at the time.
When you moved RadiusNT off the box, the spiked went away?
> To answer your question... we have tried this on a fresh install of NT,
> SP4, and SQL 7 on this same machine, but we have not tried it on other
> hardware. I would agree with you about the possibility of a SQL install
> problem, but... at the moment all fingers are pointed at Radius (the
> processes causing locks are started by Radius, and Radius don't seem to
> like running on the same box as SQL 7)
I don't have a lot of test information with RadiusNT running on the
same machine as SQL in a multiprocessor enviroment. I use a PII-300
laptop with SQL 7 and RadiusNT on the same machine for testing.
My test server is a PII-300 single proc as well.
> Taking questions one at a time... how does Radius/SQL handle it, when
> Radius is shut down (what is causing our calls table to get locked)? How
I added some code to actually stop and and disconnect all connections
in the next update. However, I've never seen RadiusNT cause the
problems
you are reporting. This may be a new issue with SQL7 that we simply
haven't uncovered yet. The only thing that can cause the table to be
locked is either an insert or update (something to change it). RadiusNT
only does inserts to the table. I suppose in theory that if RadiusNT
sent the insert w/out closing the query when it was stopped that the
last page of the calls table could be locked, but I have never seen
that.
> (if any) does this differ from connecting to a SQL 6.5 database? We are
RadiusNT doesn't know the difference between the two.
> using a system DSN via TCP/IP sockets to connect Radius to the SQL
> database. The hardware our SQL server is using is PII-333, 256MB RAM. The
> data portion of our database size is about 600MB on a properly populated
> Calls table (but is much smaller now because we have dropped our calls
> accounting history during these problems). If we can get these questions
> about why Radius is causing locks in our calls table, then we can take the
> appropriate steps to stop it from happening.
What you'll probably have to do is enable ODBC/SQL trace and then
start/stop RadiusNT to create the lock and look at the trace to see
where RadiusNT left the connection.
> Further data:
>
> ODBC version on system where Radius
> concurrency works: 3.50.0305
> (Locks on Calls table from this Radius can be cleared
> with a reboot of the SQL box)
>
> ODBC version on system where Radius concurrency
> doesn't work (SQL 7 box): 3.70.06.23
> (Locks on Calls table from this Radius can not be cleared
> with a reboot of the SQL box)
The other thing is this could be and ODBC issue. What version of the
SQL ODBC driver is on the other machine (not running SQL 7). Maybe
this is an issue with the SQL 7.0 ODBC driver?
--Dale E. Reed Jr. Emerald and RadiusNT__________________________________________IEA Software, Inc. www.iea-software.com
For more information about this list, including removal, pleasesee this URL: http://www.iea-software.com/maillist.html