[reSIProcate] asynchronous registration handling

[Scott Godin]

Ah - I see.  We have asynchronous access to db for authentication but not
for registration storage/query.  Sounds like a good thing to add to me.  : )
Scott

On Tue, Mar 10, 2009 at 10:39 AM, Justin Matthews <jmatthewsr at gmail.com>wrote:

>  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/044af017/attachment.htm>