[reSIProcate] asynchronous registration handling

Justin Matthews jmatthewsr at gmail.com
Tue Mar 10 09:39:18 CDT 2009


Sorry, it probably wasn't clear that I am looking for asynchronous database
access for registrations.  Maybe I was clear and am just missing it J.  In
ServerRegistration calls are made directly to the
RegistrationPersistenceManager (the database).  What I am looking for is a
way to send the database queries off to a worker thread and then continue
processing the REGISTER asynchronously.

 

I am thinking of sending an asynchronous request to a database thread when
the REGISTER is received to retrieve all the current records, then process
the REGISTER as it is done now once the db query is complete. The
ServerRegistration would then use a local RegistrationPersistenceManager
(similar to the inmemory store).  Once the REGISTER processing is complete
the database can be updated with another asynchronous request.  This method
would allow keeping the majority of the current logic intact. It would also
reduce some trips to the database.

 

Thanks,

 

-justin  

 

From: slgodin at gmail.com [mailto:slgodin at gmail.com] On Behalf Of Scott Godin
Sent: Tuesday, March 10, 2009 10:21 AM
To: Justin Matthews
Cc: resiprocate-devel
Subject: Re: [reSIProcate] asynchronous registration handling

 

This is already implemented in DUM for Server side registrations - or are
you referring to something different?  I'm pretty sure repro uses dum's
asynchronous db lookups as well.

2009/3/9 Justin Matthews <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


_______________________________________________
resiprocate-devel mailing list
resiprocate-devel at resiprocate.org
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20090310/067b6deb/attachment.htm>


More information about the resiprocate-devel mailing list