Re: [reSIProcate] asynchronous registration handling
Hi Rob,
Currently you would handle this by trapping all database failures in your
persistence manager and then call ServerRegistration::reject(). All the db
operations are performance before the calls to onRefresh,onRemove,onAdd,etc.
If you reject() the registration, then ServerRegistration tries to roll back
the changes by removing the registration (via removeAor()) and then
re-applying the original list that it saved (via addAor).
The implementation I am working on will allow more flexible error handling
without blocking the DUM thread, will not require roll back if the
registration is rejected and will require fewer DB calls. I should have
more details in a few days.
Thanks,
-justin
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Robert
Backhouse
Sent: Thursday, March 12, 2009 9:53 AM
To: 'resiprocate-devel'
Subject: Re: [reSIProcate] asynchronous registration handling
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@xxxxxxxxx
> <mailto:jmatthewsr@xxxxxxxxx>>
>
> 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@xxxxxxxxxxxxx>
Software Developer
Tel: +44 (0) 845 666 7778
Fax: +44 (0) 870 163 4694
http://www.mxtelecom.com
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel