[asterisk-dev] sleeping in a module
Tilghman Lesher
tilghman at mail.jeffandtilghman.com
Sat Aug 12 20:31:31 MST 2006
On Saturday 12 August 2006 11:48, Thomas Andrews wrote:
> On Sat, Aug 12, 2006 at 11:25:24AM -0500, Kevin P. Fleming wrote:
> > ----- Thomas Andrews <tandrews at grok.co.za> wrote:
> > > Do you really think so? I would have thought that the socket on
> > > the odbc interface would block if there was a lock on the db,
> > > so why can't I block too?
> >
> > I don't believe there is any concept of a database being 'locked'
> > in the ODBC world normally, although certainly queries can take
> > significant amounts of time to complete, so that's nearly the
> > same thing.
>
> I'm completely ignorant when it comes to databases. I just assumed
> that it must be possible for the underlying db (eg mysql) to have
> some kind of record locking to avoid race conditions. But I agree
> with you that delays amount to the same thing. If access is via a
> TCP socket, then there definitely will be some kind of select/poll
> between the db and odbc not so? If true, then it will definitely
> re-schedule.
To my knowledge, only TDS-based databases (i.e. Sybase and MS SQL
Server) have this limitation exposed to the user. Other databases
should correctly handle this for you, independent of user API calls.
To combat the problem in TDS-based databases, res_odbc has been
redesigned to handle multiple connections per connection class (i.e.
connection pooling). This is available in trunk and will be available
in the upcoming 1.4 release.
--
Tilghman
More information about the asterisk-dev
mailing list