[asterisk-dev] [Code Review] adding shared locks around usage of odbc handle in res_odbc

[Tilghman Lesher]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1622/#review5007
-----------------------------------------------------------


I'd be more comfortable with this change if you were able to get these crashes with Postgres, due to the number of problems over the years with the MySQL backend driver.  Forcing the connections to be unshared should have the same effect as this patch, do you agree?

- Tilghman


On Dec. 14, 2011, 3:01 a.m., wdoekes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1622/
> -----------------------------------------------------------
> 
> (Updated Dec. 14, 2011, 3:01 a.m.)
> 
> 
> Review request for Asterisk Developers and Tilghman Lesher.
> 
> 
> Summary
> -------
> 
> See bug report: under certain circumstances res_odbc can be made to crash.
> 
> Adding a shared lock around usage of the con odbc handle is a way to fix this. When a reconnect is attempted, an exclusive lock is held. Result: no usage attempts while reconnecting.
> 
> This is hacked up quickly, so could use a bit of review; it wouldn't surprise me if I double-lock something somewhere. (And the assertion I added fails too.) Also, this could be the wrong way to approach this altogether.
> 
> @tilghman: is there a reason why ->up is set to 0 after query failure? (See same question in bug report at Cause (1).)
> 
> 
> This addresses bug ASTERISK-19011.
>     https://issues.asterisk.org/jira/browse/ASTERISK-19011
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/res_odbc.h 348047 
>   /branches/1.8/res/res_odbc.c 348047 
> 
> Diff: https://reviewboard.asterisk.org/r/1622/diff
> 
> 
> Testing
> -------
> 
> With the patch, I'm not getting the easy crashes anymore.
> 
> 
> Thanks,
> 
> wdoekes
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20111214/1ac751c3/attachment.htm>