[asterisk-bugs] [JIRA] Updated: (ASTERISK-20326) res_odbc blocks datastore while a transaction waits for a lock

Christoph Sitter (JIRA) noreply at issues.asterisk.org
Mon Aug 27 09:28:08 CDT 2012


     [ https://issues.asterisk.org/jira/browse/ASTERISK-20326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christoph Sitter updated ASTERISK-20326:
----------------------------------------

    Description: 
I have set up res_odbc to use a pool of 10 connections per resource (oracle 11g connections) and I also wrote a C-Module which uses res_odbc for Oracle connection management.

What I'm doing:
  - Start a transaction
  - select for update (read + lock)
  - update
  - commit/rollback

When I now lock the row that is affected by the transaction from within another session, the "select for update" has to wait until the other session has committed it's work.
This is an expected behaviour and res_odbc does not produce any errors here.

The problem is to get a further connection.
In my case, I want to read a different row from the same table, but ast_odbc_request_obj hangs until the work is committed and the transactional "select for update" stops waiting.

I tried to find out where exactly the problem is, and I think that it is the following command:


ast_odbc_request_obj2(...) {
...
  if (class->haspool) {
    /* Recycle connections before building another */
--> obj = ao2_callback(class->obj_container, 0, aoro2_obj_cb, EOR_TX);
...
}


Hopefully this problem can be fixed soon ;)

best regards
Christoph

  was:
I have set up res_odbc to use a pool of 10 connections per resource (oracle 11g connections) and I also wrote a C-Module which uses res_odbc for Oracle connection management.

What I'm doing:
  - Start a transaction
  - select for update (read + lock)
  - update
  - commit/rollback

When I now lock the row that is affected by the transaction from within another session, the "select for update" has to wait until the other session has committed it's work.
This is an expected behaviour and res_odbc does not produce any errors here.

The problem is to get a further connection.
In my case, I want to read a different row from the same table, but ast_odbc_request_obj hangs until the work is committed and the transactional "select for update" stops waiting.

I tried to find out where exactly the problem is, and I think that it is the following command:


ast_odbc_request_obj2(...) {
...
    if (class->haspool) {
        /* Recycle connections before building another */
-->     obj = ao2_callback(class->obj_container, 0, aoro2_obj_cb, EOR_TX);
...
}


Hopefully this problem can be fixed soon ;)

best regards
Christoph


> res_odbc blocks datastore while a transaction waits for a lock
> --------------------------------------------------------------
>
>                 Key: ASTERISK-20326
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-20326
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: 10.7.0
>         Environment: RHEL 2.6.32-220.el6.x86_64 GNU/Linux
>            Reporter: Christoph Sitter
>
> I have set up res_odbc to use a pool of 10 connections per resource (oracle 11g connections) and I also wrote a C-Module which uses res_odbc for Oracle connection management.
> What I'm doing:
>   - Start a transaction
>   - select for update (read + lock)
>   - update
>   - commit/rollback
> When I now lock the row that is affected by the transaction from within another session, the "select for update" has to wait until the other session has committed it's work.
> This is an expected behaviour and res_odbc does not produce any errors here.
> The problem is to get a further connection.
> In my case, I want to read a different row from the same table, but ast_odbc_request_obj hangs until the work is committed and the transactional "select for update" stops waiting.
> I tried to find out where exactly the problem is, and I think that it is the following command:
> ast_odbc_request_obj2(...) {
> ...
>   if (class->haspool) {
>     /* Recycle connections before building another */
> --> obj = ao2_callback(class->obj_container, 0, aoro2_obj_cb, EOR_TX);
> ...
> }
> Hopefully this problem can be fixed soon ;)
> best regards
> Christoph

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list