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

[Dave Singer]

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
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>