Module: sip-router Branch: 4.1 Commit: f6dfa8d5e91b287ceccb84659448ee1aadbfc486 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f6dfa8d5...
Author: Carsten Bock carsten@ng-voice.com Committer: Carsten Bock carsten@ng-voice.com Date: Thu Jan 30 21:55:11 2014 +0100
presence: bugfix: Add option to disable per-Table lock for database layer (causes trouble with MySQL in DB_ONLY mode)
---
modules/presence/doc/presence_admin.xml | 22 ++++++++++++++++++++++ modules/presence/notify.c | 6 +++--- modules/presence/presence.c | 7 +++++++ modules/presence/presence.h | 2 ++ modules/presence/presentity.c | 4 ++-- modules/presence/subscribe.c | 4 ++-- 6 files changed, 38 insertions(+), 7 deletions(-)
diff --git a/modules/presence/doc/presence_admin.xml b/modules/presence/doc/presence_admin.xml index 02b3562..8b18174 100644 --- a/modules/presence/doc/presence_admin.xml +++ b/modules/presence/doc/presence_admin.xml @@ -575,6 +575,28 @@ modparam("presence", "fetch_rows", 1000) </programlisting> </example> </section> + <section> + <title><varname>db_table_lock_type</varname> (integer)</title> + <para> + Enable (=1) or disable (=0) the Locks for table during an transaction. + Locking only the "current" table causes problems with a MySQL-Databases + in "DB-Only" mode. + </para> + <para> + <emphasis> + Default value is 1 (Write Lock for the Tables). + </emphasis> + </para> + <example> + <title>Set <varname>db_table_lock_type</varname> parameter</title> + <programlisting format="linespecific"> +... +modparam("presence", "db_table_lock_type", 0) +... +</programlisting> + </example> + </section> +
</section>
diff --git a/modules/presence/notify.c b/modules/presence/notify.c index 0a7ffb2..402aacc 100644 --- a/modules/presence/notify.c +++ b/modules/presence/notify.c @@ -1335,7 +1335,7 @@ int publ_notify_notifier(str pres_uri, pres_ev_t *event)
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; @@ -2701,7 +2701,7 @@ int process_dialogs(int round, int presence_winfo)
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; @@ -2810,7 +2810,7 @@ int process_dialogs(int round, int presence_winfo)
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; diff --git a/modules/presence/presence.c b/modules/presence/presence.c index 067a1e1..6a87776 100644 --- a/modules/presence/presence.c +++ b/modules/presence/presence.c @@ -149,6 +149,9 @@ int pres_waitn_time = 5; int pres_notifier_poll_rate = 10; int pres_notifier_processes = 1;
+int db_table_lock_type = 1; +db_locking_t db_table_lock = DB_LOCKING_WRITE; + int *pres_notifier_id = NULL;
int phtable_size= 9; @@ -199,6 +202,7 @@ static param_export_t params[]={ { "timeout_rm_subs", INT_PARAM, &timeout_rm_subs}, { "send_fast_notify", INT_PARAM, &send_fast_notify}, { "fetch_rows", INT_PARAM, &pres_fetch_rows}, + { "db_table_lock_type", INT_PARAM, &db_table_lock_type}, {0,0,0} };
@@ -401,6 +405,9 @@ static int mod_init(void) register_basic_timers(pres_notifier_processes); }
+ if (db_table_lock_type != 1) + db_table_lock = DB_LOCKING_NONE; + pa_dbf.close(pa_db); pa_db = NULL;
diff --git a/modules/presence/presence.h b/modules/presence/presence.h index e064bb2..b94e4dc 100644 --- a/modules/presence/presence.h +++ b/modules/presence/presence.h @@ -94,6 +94,8 @@ extern int pres_notifier_processes; extern int phtable_size; extern phtable_t* pres_htable;
+extern db_locking_t db_table_lock; + int update_watchers_status(str pres_uri, pres_ev_t* ev, str* rules_doc); int pres_auth_status(struct sip_msg* msg, str watcher_uri, str presentity_uri);
diff --git a/modules/presence/presentity.c b/modules/presence/presentity.c index 47a828a..6d7ffd5 100644 --- a/modules/presence/presentity.c +++ b/modules/presence/presentity.c @@ -426,7 +426,7 @@ int update_presentity(struct sip_msg* msg, presentity_t* presentity, str* body,
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; @@ -1195,7 +1195,7 @@ int mark_presentity_for_delete(presentity_t *pres)
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; diff --git a/modules/presence/subscribe.c b/modules/presence/subscribe.c index aff55f3..75e0c9c 100644 --- a/modules/presence/subscribe.c +++ b/modules/presence/subscribe.c @@ -863,7 +863,7 @@ int handle_subscribe(struct sip_msg* msg, str watcher_user, str watcher_domain) LM_ERR("unsuccessful use_table sql operation\n"); goto error; } - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error; @@ -1662,7 +1662,7 @@ void update_db_subs_timer_notifier(void)
if (pa_dbf.start_transaction) { - if (pa_dbf.start_transaction(pa_db, DB_LOCKING_WRITE) < 0) + if (pa_dbf.start_transaction(pa_db, db_table_lock) < 0) { LM_ERR("in start_transaction\n"); goto error;
Carsten Bock writes:
presence: bugfix: Add option to disable per-Table lock for database layer (causes trouble with MySQL in DB_ONLY mode)
...
<title><varname>db_table_lock_type</varname> (integer)</title>
<para>
Enable (=1) or disable (=0) the Locks for table during an transaction.
Locking only the "current" table causes problems with a MySQL-Databases
in "DB-Only" mode.
does it make sense to disable the locks? i would imagine that they were introduced for a purpose. what can break if locks are not used?
does the same MySQL trouble exist with locks used in rls module?
-- juha
Hi Juha,
all i can say is, that the locks make the presence module completely unusable with a MySQL backend in DB_ONLY mode. The current database layer will only lock the current table for a transaction, not all tables used during one transaction. And that results in an unusable database connection. In order to change that, i'd have to the complete database API. .. The RLS-Module has a similar option already...
Kind regards, Carsten Am 01.02.2014 20:38 schrieb "Juha Heinanen" jh@tutpro.com:
Carsten Bock writes:
presence: bugfix: Add option to disable per-Table lock for database layer (causes trouble with MySQL in DB_ONLY mode)
...
<title><varname>db_table_lock_type</varname> (integer)</title>
<para>
Enable (=1) or disable (=0) the Locks for table during an
transaction.
Locking only the "current" table causes problems with a
MySQL-Databases
in "DB-Only" mode.
does it make sense to disable the locks? i would imagine that they were introduced for a purpose. what can break if locks are not used?
does the same MySQL trouble exist with locks used in rls module?
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Carsten Bock writes:
all i can say is, that the locks make the presence module completely unusable with a MySQL backend in DB_ONLY mode. The current database layer will only lock the current table for a transaction, not all tables used during one transaction. And that results in an unusable database connection. In order to change that, i'd have to the complete database API. .. The RLS-Module has a similar option already...
What option is that? I could not find any lock related option in rls module README.
-- Juha
Hi Juha,
you're right... weird: I wonder, where i did see that.
Carsten
2014-02-04 22:32 GMT+01:00 Juha Heinanen jh@tutpro.com:
Carsten Bock writes:
all i can say is, that the locks make the presence module completely unusable with a MySQL backend in DB_ONLY mode. The current database layer will only lock the current table for a transaction, not all tables used during one transaction. And that results in an unusable database connection. In order to change that, i'd have to the complete database API. .. The RLS-Module has a similar option already...
What option is that? I could not find any lock related option in rls module README.
-- Juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev