It was a reply to this
http://n2.nabble.com/Mysql-stored-proc-td3060191.html#a3060191
Sorry about that.
On Jan 19, 2010 4:15am, "Bogdan-Andrei Iancu [via OpenSIPS (Open SIP
Server)]" wrote:
> Hi,
> OpenSIPS does not directly provide you these two values, but you can
> simply calcul
Hi,
OpenSIPS does not directly provide you these two values, but you can
simply calculate them. Like for PDD: you save the timestamp when the
invite came and also the timestamp of the 180 to see the difference.
BTW, what is with the subject - "mysql stored proc" ? there is nothing
about it in
I am in the process of putting all the OpenSIPS modules and AG Projects
together to create a carrier-grade service and think this is something that
can be used. I am far from implementing what you speak of above, but it
would be very helpful. Nothing is better then saving money but not at the
ex
Well I've heard of a bunch of carriers now doing what they call "dynamic
LCR". Here's the issues at hand with carrier LCRs:1. Depending on
jurisdiction, I route differently (interstate, intrastate, international,
etc). External factors can determine jurisdiction. I use memcache + some
pattern match
Hi Brett,
Brett Nemeroff wrote:
Ok, well I'll try this out for performance. I'm curious to see what
I'd be able to handle doing live mysql routing decisions with all the
new prepared statements and such.
note that not all the DB ops are using prepared statements - most of the
modules do use it
Ok, well I'll try this out for performance. I'm curious to see what I'd be
able to handle doing live mysql routing decisions with all the new prepared
statements and such.
Of course, I'm a big proponent of doing memory routing, but I may need some
capabilities to route based on other factors such a
hard to say - to be honest I never used "temporary" tables - I just
commented from the opensips point of view, on how the mysql connections
are managed.
Regards,
Bogdan
Brett Nemeroff wrote:
> Ok, so basically I build a temp table called "routes" from a stored
> proc. Can I not rely on this be
Ok, so basically I build a temp table called "routes" from a stored proc.
Can I not rely on this being a unique table per transaction if the session
is held alive? Of course I could name the table something like
routes__<$ru> and trash it at the end of the stored proc. I just
don't want to end up w
> But yes, the memcache is a good option :). especially that we are working on
> interfacing the memcache interface with the memcached daemon ;)
>
That's really cool, keep up the good work :)
Regards,
--
Saúl -- "Nunca subestimes el ancho de banda de un camión lleno de disketes."
-
Saúl Ibarra wrote:
>> Each OpenSIPS process opens at startup a mysql connection and it keeps it
>> open till the shutdown - so the connection is persistent at runtime. Of
>> course, a conection can be re-established at runtime if some connection lost
>> event happens (timesout etc).
>>
>>
>
>
>
> Each OpenSIPS process opens at startup a mysql connection and it keeps it
> open till the shutdown - so the connection is persistent at runtime. Of
> course, a conection can be re-established at runtime if some connection lost
> event happens (timesout etc).
>
That's good to know :) But don't
Hi Saúl,
Saúl Ibarra wrote:
>
>
> I don't really know how OpenSIPS handles MySQL connections, but that
> approach may fail if connection is lost, etc. As a suggestion
> (somebody correct me if I'm wrong) you could use memory caching
> options (http://www.opensips.org/Resources/DocsTutMemcache
As you said, and according to MySQL doc, temporary tables are just
'alive' during a connection.
"""You can use the TEMPORARY keyword when creating a table. A
TEMPORARY table is visible only to the current connection, and is
dropped automatically when the connection is closed. This means that
two d
All,I'm using a mysql stored proc in an avp_db_query. Part of the stored
proc creates a temporary table. Temporary tables are only available during
the same session. Question is, is each dialog in it's own session? Where
will my temporary table be available from?
Thanks,
Brett
14 matches
Mail list logo
