запись в sqlite базу из многопоточного приложения

Транзакции и локи.

часто после вставки нужно взять last inserted id.

ВДОЛЬ!

а чего вдоль то?
всегда было так, что после сохранения в базу, требуется заполнить поле ключа в entity.

пока что склоняюсь к этому

Как оно поможет взять last inserted id?

Безопаснее всего выделить один поток под базу и отправлять ему задачи, когда нужно что-то узнать после вставки, — блокирующие.

всегда было так, что после сохранения в базу, требуется заполнить поле ключа в entity.

+1 К примеру, на ЛОР-е когда пишешь коммент, тебя сразу редиректит на страницу к твоему комменту. ( linux.org.ru/forum/category/666#message_id_22 ).

Я так понимаю, что без last_id это было бы невозможно сделать.

вроде как last inserted id хранится только в sqlite3*, так что вариантов по сути всего два:

а) лочить всю БД с помощью мутекса - sqlite3_db_mutex б) вынести работу с БД в один поток

а он разве не в пределах конекшна?

а чего вдоль то?

А того. Что этоксотыль

всегда было так, что после сохранения в базу, требуется заполнить поле ключа в entity.

автоинкремент всегда был потенциальной проблемой. И решали её всегда одинаково - сиквенсом.

автоинкремент всегда был потенциальной проблемой. И решали её всегда одинаково - сиквенсом.

где хоть слово было про автоинкремент? сиквенс - это правильно, я согласен.

И решали её всегда одинаково - сиквенсом.

для тех кто в танке — что это такое?

В треде замечены тяжелые вещества. Какие, блжад, мьютексы и локи??? Вы упоролись что ли?

import sqlite3

from threading import Thread
from itertools import groupby

create_stm = """CREATE TABLE IF NOT EXISTS boo (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title varchar(50)
)"""

def get_conn(path):
    conn = sqlite3.Connection(path, timeout=60)
    return conn

def create_db(conn):
    conn.execute(create_stm)
    conn.commit()

def writer(path, data):
    conn = get_conn(path)
    cursor = conn.cursor()
    for _ in xrange(1000):
        cursor.execute('INSERT INTO boo(title) VALUES (?)', ('boo',))
        conn.commit()
        data.append(cursor.lastrowid)


db_name = '/tmp/boo.db'
create_db(get_conn(db_name))
data = []
threads = []

for _ in xrange(10):
    t = Thread(target=writer, args=(db_name, data))
    t.start()
    threads.append(t)

for t in threads:
    t.join()

for k, v in groupby(sorted(data)):
    assert len(list(v)) == 1, k

для тех кто в танке — что это такое?

sequence

там гдето была функция с waitом

Как оно поможет взять last inserted id?

думал извлекать last inserted id в том же блоке что и инсерт. тоесть всегда (при инсерте). чем этот подход плох (кроме небольшого оверхеда)?

когда нужно что-то узнать после вставки, — блокирующие.

чтото голова уже не варит. разьясните поподробнее

Ссылка в начале ведет на пул потоков (workers), не очень представляю, как это может помочь в синхронизации доступа. Или может, синхронизация вообще не нужна?

В треде замечены тяжелые вещества.

добро пожаловать из уютного мира питона в темный мир С и библиотек на нем

import sqlite3
...

еще раз убеждаюсь, что питон - ужасный ЯП, мало того, что там GIL, так еще:

а) твой пример не работает на python3 (не проблема была исправить, но...)
б) ты его сам запускал? там сплошные исключения: «OperationalError: database is locked», да-да - «Какие, блжад, мьютексы и локи???», именно так

Тут и думать-то нечего.

http://www.sqlite.org/c3ref/last_insert_rowid.html

This routine returns the rowid of the most recent successful INSERT into the database from the database connection in the first argument.

Использование тредпула ортогонально получению идентификатора.

cursor = conn.cursor()

почему оно гуглится только для питона? даже на сайте sqlite я ничего не нашел

«OperationalError: database is locked»

Чтобы этого не было, можно синхронизировать средствами самого sqlite: http://sqlite.org/c3ref/busy_timeout.html

в пуле 1 воркер - вот и есть синхронизация

добро пожаловать из уютного мира питона в темный мир С и библиотек на нем

http://www.sqlite.org/c3ref/last_insert_rowid.html

Тоже самое.

a) python3 не нужен

б) УМВРЧЯДНТ?

мало того, что там GIL

Сдается мне, ты не знаешь матчасти.

Тоже самое.

не тоже самое, sqlite3_last_insert_rowid нельзя использовать из нескольких потоков вот так просто

Сдается мне, ты не знаешь матчасти.

может быть, насколько я знаю - есть реализации свободные от GIL, но это немногое меняет

Ссылка на сайт sqlite уже была.

В догонку:

http://sqlite-ruby.rubyforge.org/sqlite3/classes/SQLite3/Database.html#M000109

sqlite3_last_insert_rowid нельзя использовать из нескольких потоков вот так просто

Если не заметил, то в примере у каждого потока свой коннекшен. Учи матчасть, что еще могу сказать.

но это немногое меняет

ИЧСХ, в подавляющем числе случаев GIL мешает кому угодно, только не питонистам.

sqlite3_last_insert_rowid нельзя использовать из нескольких потоков вот так просто

Один sqlite3* вообще нельзя использовать из нескольких нитей.

Если не заметил, то в примере у каждого потока свой коннекшен.

если ты еще не заметил - твой пример нерабочий, а знаешь почему? я в тебя верю - ты догадаешься

ИЧСХ, в подавляющем числе случаев GIL мешает кому угодно, только не питонистам.

за сколько у тебя этот пример выполняется? ;) у меня он выполняется оооочень долго, а пример с потоками на С выполнится практически мгновенно

Один sqlite3* вообще нельзя использовать из нескольких нитей.

так было до версии 3.3.1

Тогда это превращается в обработку очереди в выделенном потоке, которую я и предлагал.

если ты еще не заметил - твой пример нерабочий

Гм, было бы очень интересно снять шляпу, но навряд ли перед тобой.

у меня он выполняется оооочень долго

Уверяю, в этом не GIL виноват, хе-хе.

за сколько у тебя этот пример выполняется?

4с на атоме.

Гм, было бы очень интересно снять шляпу, но навряд ли перед тобой.

не стоит, конечно

Уверяю, в этом не GIL виноват, хе-хе.

да - в этом виноват лично ты, написавший нерабочий и оооочень медленный код

написавший нерабочий и оооочень медленный код

Походу, не работает он только у тебя, бедная жертва мейнтейнеров. У меня он прекрасно себя чувствует и под вторым и под третьим питоном.

Кстати, давай свой код, чо.

кхм, у меня тоже твой код тоже «нерабочий и оооочень медленный»

валится с ошибками, как указали выше

OperationalError: database is locked

python 2.7.2 в генту

мало того, что там GIL

Хватит уже чушь пороть. Всегда удивляли люди, которые наслушаются умных словечек, и козыряют ими, направо и налево.

Что я могу сказать? Видимо, так собран sqlite или питонячье расширение. Переделал с мультипроцессингом — все равно работает.

Хватит уже чушь пороть

вы о чем?

Всегда удивляли люди, которые наслушаются умных словечек, и козыряют ими, направо и налево.

совсем не из таких, но разве GIL не ограничивает производительность? я готов слушать, и не против, если мне что-то объяснят

вы о чем?

Извините, я немного резко высказался.

совсем не из таких, но разве GIL не ограничивает производительность? я готов слушать, и не против, если мне что-то объяснят

Не накладывает он столько ограничений, сколько о нем говорят. Примеров масса.

Не накладывает он столько ограничений, сколько о нем говорят. Примеров масса.

не буду спорить, действительно слышал о них только в теории

Походу, не работает он только у тебя, бедная жертва мейнтейнеров

okay

Кстати, давай свой код, чо.

#include <csignal>
#include <set>
#include <sqlite3.h>
#include <thread>
using namespace std;

int main() 
{
    sqlite3* db;
    sqlite3_open_v2( ":memory:", &db, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, 0 );
    sqlite3_exec( db, "CREATE TABLE boo( id INT PRIMARY KEY AUTOINCREMENT, title TEXT)", 0, 0, 0 );

    set<int> ids;
    for( size_t i = 0 ; i < 10 ; ++i )
        thread( [db,&ids] {
            for( size_t j = 0 ; j < 1000 ; ++j )
            {
                sqlite3_mutex_enter( sqlite3_db_mutex(db) );
                sqlite3_exec( db, "INSERT INTO boo(title) VALUES ('boo')", 0, 0, 0 );
                if( !ids.insert( sqlite3_last_insert_rowid(db) ).second ) raise( SIGTRAP );
                sqlite3_mutex_leave( sqlite3_db_mutex(db) );
            }
        } ).join();
}

Я знал, я знал.

1) Пиши в файл

2) Делай commit.

Где теперь твоя скорость?

Я знал, я знал.
Где теперь твоя скорость?

давай поочереди предъявлять требования - напиши вариант с работой в памяти, это будет правильный бенчмарк кода примера, а не скорости записи на диск, сразу после этого я переделаю на диск, ок?

ну и для такого случая давай по 1млн итераций в потоке, т.к. на тысяче мерять нечего

OperationalError: database is locked

Всё, вспомнил где косяк. Надо соединения заранее открывать.

import sqlite3

from threading import Thread
from itertools import groupby
from Queue import Queue

create_stm = """CREATE TABLE IF NOT EXISTS boo (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    title varchar(50)
)"""

def get_conn(path):
    conn = sqlite3.Connection(path)
    return conn

def create_db(conn):
    conn.execute(create_stm)
    conn.commit()

def writer(path, data, q):
    conn = get_conn(path)
    cursor = conn.cursor()
    count = 0
    while q.get(True):
        count += 1
        cursor.execute('INSERT INTO boo(title) VALUES (?)', ('boo',))
        conn.commit()
        data.append(cursor.lastrowid)

    print count

db_name = '/tmp/boo.db'
create_db(get_conn(db_name))
data = []
threads = []
q = Queue(1000)

for _ in range(4):
    t = Thread(target=writer, args=(db_name, data, q))
    t.start()
    threads.append(t)

for _ in range(10000):
    q.put(True)

for _ in threads:
    q.put(False)

for t in threads:
    t.join()

for k, v in groupby(sorted(data)):
    assert len(list(v)) == 1, k

напиши вариант с работой в памяти

У каждого соединения своя :memory:. Поэтому невозможно.

А без коммита у меня тоже мгновенно отрабатывает. sync всегда был очень дорогой операцией.

Поэтому невозможно.

я правильно понял? в питоне _невозможно_ из двух потоков писать в один кеш, например? не верю, ты просто не подумал хорошо

А без коммита у меня тоже мгновенно отрабатывает

а у меня нет, хотя я же забыл - я же «бедная жертва мейнтейнеров», все верно, так и должно быть

Всё, вспомнил где косяк. Надо соединения заранее открывать.

кстати косяк конечно не в этом, этот вариант все так же сыплет: OperationalError: database is locked

я правильно понял?

Нет. Тебе ручник мешает. Расшифровываю — мой вариант (без локов), используя несколько соединений на :memory: невозможен.

Нет. Тебе ручник мешает

а я уже надейлся на культурный разговор

Расшифровываю — мой вариант (без локов), используя несколько соединений на :memory: невозможен.

ес-но, я это изначально знал ;)

этот вариант все так же сыплет: OperationalError: database is locked

И ты, конечно же, не менял ни одной строчки кода?

ну и попробуй, попробуй уже догадаться в чем причина ошибки «OperationalError: database is locked», это не сложно