[Freeswitch-users] Question regarding UUID stacking in a FIFO

[Steven Ayre]

Since realm+key are a unique pair storing a single value you can't do it
with mod_db. Anything build around fetching,editing,storing the value will
be subject to race conditions if there are 2 concurrent calls accessing it.

You could implement this yourself using a custom transactional database and
accessing it in Lua via freeswitch.Dbh. Begin a transaction, select the
first UUID ordered by perhaps insertion uepoch, delete that uuid, commit,
then use that uuid. Using SELECT FOR UPDATE will prevent another concurrent
call getting the same uuid - the other will block until the commit at which
point it's no longer in the table. That blocking should be fine because
it's a very short transaction. Just insert another row to push a new uuid
onto the stack.

On 23 June 2016 at 15:35, David Ponzone <david.ponzone at gmail.com> wrote:

> Guys,
>
> I am searching for a way to stack UUID into a FIFO.
> What I need is something like db insert/realm/key/${uuid} or hash
> insert/realm/key/${uuid} but that I need to keep several uuids with the
> same realm/key tuple.
>
> The ideal would be:
> I first insert realm/key/${uuid1}
> then insert real/ley/{uuid2}
>
> then if I do select/realm/key, it pops out ${uuid1)
> I can then manually remove it, and the next select will pop out ${uuid2}
>
> I don’t think it’s possible with hash/db, so does anyone a way/trick to
> achieve that ?
>
> (the goal is to intercept several simultaneous incoming calls in the
> RINGING state)
>
> Thank you
>
> David Ponzone  Direction Technique
> email: david.ponzone at ipeva.fr
> tel:      01 74 03 18 97
> gsm:   06 66 98 76 34
>
> Service Client IPeva
> tel:      0811 46 26 26
> www.ipeva.fr  -   www.ipeva-studio.com
>
> *Ce message et toutes les pièces jointes sont confidentiels et établis à
> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
> non autorisée est interdite. Tout message électronique est susceptible
> d'altération. **IPeva** décline toute responsabilité au titre de ce
> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
> destinataire de ce message, merci de le détruire immédiatement et d'avertir
> l'expéditeur.*
>
>
>
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20160624/89225b30/attachment.html