[reSIProcate] asynchronous registration handling

[Robert Backhouse]

Hi,

I have a separate but related question. In the last few days I have also 
been having trouble in this area while trying to implement a 
database-based RegistrationPersistenceManager.

My problem is that there doesn't seem to be any mechanism to cope with 
an action/query failing - if there is a problem with the database 
connection, the SQL syntax, or just a random deadlock or transaction 
timeout then I can't see a way to fail the registration.

I presume some people must have successfully written database backed 
RegistrationPersistenceManager implementations - can anyone explain how 
they dealt with SQL exceptions without a response to signify failure or 
a suitable exception to throw?

Otherwise, if the ServerRegistration logic is being rewritten, do you 
think this would be a sensible opportunity to support failures from the 
RegistrationPersistenceManager in some way?

Thanks,

Rob.


> 2009/3/9 Justin Matthews <jmatthewsr at gmail.com 
> <mailto:jmatthewsr at gmail.com>>
> 
> Hi,
> 
> I am looking at adding asynchronous REGISTER handling in DUM. Has anyone 
> thought about or actually implemented this?  There are some notes in 
> DialogSet.cxx about moving REGISTER handling to DialogUsageManager, 
> would these mean converting REGISTER handling to be a DumFeature?  Would 
> this makes things easier to post back responses to a DUM feature as 
> opposed to implementing some kind of postback to a ServerRegistration?    
> 
> Basically I need to send the DB queries off to another thread to avoid 
> blocking.
> 
> Also, is anyone else interested in this?
> 
> Thanks,
> 
> justin

-- 
Robert Backhouse <robertb at mxtelecom.com>
Software Developer
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com