On Mon, May 22, 2017 at 10:06 AM, marek cervenka <[email protected]> wrote: > hi, > > first of all, i know sqlite is not designed for concurrency > > workarounds are wal - https://www.sqlite.org/wal.html . can be specified > when creating DB with "pragma journal_mode=wal" > > and > > busy_timeout https://www.sqlite.org/c3ref/busy_timeout.html . MUST be > specified per connection > > > we are using sqlite for cel and queue_log. > > https://github.com/asterisk/asterisk/blob/master/res/res_config_sqlite3.c > > https://github.com/asterisk/asterisk/blob/master/cel/cel_sqlite3_custom.c > > busy_timeout is hardcoded (value is in ms) > > sqlite3_busy_timeout(db->handle, 1000); > > > will you accept patch where busy_timeout will be configurable? > > > btw our use case is > > - central data warehouse > > - apache kafka as receiver > > - every asterisk has producer (node.js) which analyze sqlite cel/queue_log. > producer builds call structure and send it to kafka. main problem is in > updating sqlite cel/queue_log by producer which rows was sent (concurrent > write access)
I don't specifically have a problem with making busy_timeout configurable, as long as it has the same default value as it is now. That's just one guy's opinion though :-) --- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
