[OpenSIPS-Users] Asynchronous DB queries in OpenSIPS 1.x

[Bogdan-Andrei Iancu]

Hi Dave,

We decided to put the async support in core (the mechanism for "moving" 
a query from current process to a DB process) - each DB module will 
choose to use or not this async support (like for db_text makes not 
sense, db_postgres may have a buitin one, etc)

Regards,
Bogdan

On 03/16/2011 11:26 PM, Dave Singer wrote:
> Vlad,
> Would it be possible extend DB_VITRUAL kind of a combination of your
> two options and Brett's suggestion.
> I'm just guessing how things might work and possibilities. So for what
> it is worth...
> Since it is a middle layer, it could either use the async capabilities
> of the native driver or put it in a queue to be handled by a special
> db queue process that could also be threaded potentially (if
> beneficial). The IPC would only need to pass the query that is needed.
> To take advantage of the async the user would only need to use the
> DB_VIRTUAL module.
> Probably would want a module param to enable/disable async
> (async_db_updates) in case it is important and maybe a bit flag option
> as well that would reverse the async_db_updates option when flag set
> for case by case basis.
> Potentially with a separate queue process updates like registrations
> could be combined into a single update.
>
> Dave
>
>
> On Wed, Mar 16, 2011 at 10:32 AM, Brett Nemeroff<brett at nemeroff.com>  wrote:
>>
>>
>>
>> On Wed, Mar 16, 2011 at 12:18 PM, Vlad Paiu<vladpaiu at opensips.org>  wrote:
>>> Hello all,
>>>
>>> Problem :
>>> 1) Extend the OpenSIPS DB core. Add extra core processes that would only
>>> handle queries that return no results.
>>>      For example : The accounting module need to insert an entry in the DB.
>>> The module calls the insert() function. Behind the scene, this triggers
>>> passing all the arguments to the new core processes, via IPC mechanisms. The
>>> insert() then exists and the SIP children continues execution as if the
>>> entry has been inserted in the DB. Meanwhile, the DB core processes receive
>>> the new parameters, build and send the query, blocking if necessary.
>>>
>> Maybe I'm just saying the same thing another way, but what about an async
>> execution queue. So you basically add to the queue messages to be executed
>> to the database and on some sort of timer loop process them. To the script,
>> we just assume everything is 100% successful.
>> Is IPC really necessary for this? The goal here is really just to offload
>> the processing elsewhere so that the DB slowness doesn't adversely affect
>> opensips core performance. right?
>>
>> I thin it's also important that there is a async execute and a sync execute
>> and people (users?) need to know that in the async execute, you won't know
>> if the execute succeeded in the script logic *ever*
>> -Brett


-- 
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"