Hi Klaus,

By wrapping the queries into a DB transaction do you mean something along the lines of doing BEGIN/COMMIT/ROLLBACK in PostgreSQL around some sets of transactions?  For example, the query selecting records with the updated flag set and subsequent query to unset the flag?

If so this would be good to prevent multiple servers attempting to do the same set of updates at the same time.  Is there an easy (and DB independent) way to do this Kamailio?

I am not sure I understand the issue about auto_reconnect?

Thanks,

Peter

On Fri, 2012-04-20 at 10:03 +0200, Klaus Darilion wrote: 
Hi Peter!

I remember we had some discussion that same queries may be wrapped into 
a DB transaction to avoid inconsistencies when using multiple presence 
servers.

I just wonder if this is now the case or not. Because then, 
auto_reconnect in the DB module must be disabled as it may happen that 
the connection is closed/connected during a transaction.

regards
Klaus

On 18.04.2012 18:36, Peter Dunkley wrote:
> Module: sip-router
> Branch: master
> Commit: dff68160e4decc43f2da8948ea03bc4d469ded96
> URL:    http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=dff68160e4decc43f2da8948ea03bc4d469ded96
>
> Author: Peter Dunkley<peter.dunkley@crocodile-rcs.com>
> Committer: Peter Dunkley<peter.dunkley@crocodile-rcs.com>
> Date:   Wed Apr 18 17:29:32 2012 +0100
>
> modules_k/rls: RLS full-state NOTIFY requests now sent by notifier process(es)
>
> - Also modified the notifier process stuff to only work when in
>    DB only mode.  This is because the full-state handling stuff
>    in the notifier processes relies on DB only mode.
> - Leaving the full-state stuff outside of the notifier process
>    didn't work because there was a row update race between the
>    notifier process and non-notifier process when full-state and non-
>    full-state NOTIFY requests were generated at the same time.
> - This ensures that (with default options) you get at most one NOTIFY
>    (or set of NOTIFYs when splitting large NOTIFYs is enabled) per
>    5s per watcher from RLS.
> - It also helps spread out the NOTIFY generation load more evenly
>    across time.
>
> ---
>
>   modules_k/rls/README            |    6 ++
>   modules_k/rls/doc/rls_admin.xml |    8 ++
>   modules_k/rls/resource_notify.c |  175 +++++++++++++++++++++++++++++++++++++--
>   modules_k/rls/rls.c             |   25 ++++--
>   modules_k/rls/rls.h             |    3 +
>   modules_k/rls/rls_db.c          |   20 ++++-
>   modules_k/rls/subscribe.c       |   40 ++++++----
>   7 files changed, 240 insertions(+), 37 deletions(-)
>
> Diff:   http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=dff68160e4decc43f2da8948ea03bc4d469ded96
>
> _______________________________________________
> sr-dev mailing list
> sr-dev@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd