Ok, well I&#39;ll try this out for performance. I&#39;m curious to see what I&#39;d be able to handle doing live mysql routing decisions with all the new prepared statements and such. <div><br></div><div>Of course, I&#39;m a big proponent of doing memory routing, but I may need some capabilities to route based on other factors such as ASR and PDD to automatically set the route priorities. Maybe a module someday.. :D</div>

<div><br></div><div>-Brett</div><div><br></div><div><br><div><br><div class="gmail_quote">On Sun, Jun 14, 2009 at 1:06 PM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">hard to say - to be honest I never used &quot;temporary&quot; tables - I just commented from the opensips point of view, on how the mysql connections are managed.<br>


<br>
Regards,<br>
Bogdan<br>
<br>
Brett Nemeroff wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Ok, so basically I build a temp table called &quot;routes&quot; 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_&lt;timestamp&gt;_&lt;$ru&gt; and trash it at the end of the stored proc. I just don&#39;t want to end up with a race condition.<br>


<br>
<br></div><div class="im">
On Thu, Jun 11, 2009 at 3:28 AM, Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> &lt;mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>&gt;&gt; wrote:<br>


<br>
    Saúl Ibarra wrote:<br>
    &gt;&gt; Each OpenSIPS process opens at startup a mysql connection and<br>
    it keeps it<br>
    &gt;&gt; open till the shutdown - so the connection is persistent at<br>
    runtime. Of<br>
    &gt;&gt; course, a conection can be re-established at runtime if some<br>
    connection lost<br>
    &gt;&gt; event happens (timesout etc).<br>
    &gt;&gt;<br>
    &gt;&gt;<br>
    &gt;<br>
    &gt; That&#39;s good to know :) But don&#39;t you think it&#39;s a bit risky to<br>
    rely on<br>
    &gt; temporary tables in this case? If by any chance the connection<br>
    is lost<br>
    &gt; strange things ca start to happen :-O ? I&#39;d go for memcache ;)<br>
    &gt;<br>
    well, opensips takes care of its internal DB stuff (like re-init the<br>
    prepared statements after a reconnect), but for other things you do by<br>
    yourself from script, you need to take care by yourself :)<br>
<br>
    But yes, the memcache is a good option :). especially that we are<br>
    working on interfacing the memcache interface with the memcached<br>
    daemon ;)<br>
<br>
    Regards,<br>
    Bogdan<br>
<br>
    _______________________________________________<br>
    Users mailing list<br></div>
    <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> &lt;mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>&gt;<div class="im"><br>
    <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div></div>