| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
What
are your thoughts on moving registration to DialogUsageManager (as mentioned by
!jf! in the comments)? Would this be a DUM Feature? This might help in
sending back asynchronous responses to DUM. Thanks, -justin From: slgodin@xxxxxxxxx
[mailto:slgodin@xxxxxxxxx] On Behalf Of 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@xxxxxxxxx> 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@xxxxxxxxx
[mailto:slgodin@xxxxxxxxx]
On Behalf Of Scott Godin 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@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
|