Hi,
We have two radiator servers, each with their own MSSQL server connected via
MSSQL replication. One radiator server is our primary and the other is the
secondary handling overflow (or in the case of the primary being down, the
full-load)
On the primary MSSQL server we run a cleanup stored-procedure that maintains
session database integrity utilising Checkpoint records.
Due to the fact that Radiator/Replication and the cleanup routine all use
the working databases (RADONLINE/CHECKPOINTTABLE) we are having a number of
database contention issues causing deadlocks. We are currently employ a
variety of different locking methodogies and priortising the radius requests
wherever possible which keeps stability high.
This solution has some downsides, particularly if we have to restart/resync
replication as it does not honor our locking requirements as well as we
would like.
My Question is:
Is it possible to maintain session control in a custom application instead
of a table on a database?
Do you see any potential issues in pursuing this idea?
The reason:
We would potentially like to develop an application that is passed requests
to add/delete/query a session database that we can queue and control
concurrency, internal replication could still be handled with a view to
prioritise radius requests.
Regards,
Lincoln
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
