Re: [sqlite] threads and last_insert_rowid()

On Tue, Nov 16, 2010 at 09:35:21AM -0500, Pavel Ivanov scratched on the wall: > But as I see in SQLite sources sqlite3_exec does acquire > connection's mutex, so nothing can be executed in between statements. > Thus if you execute this line as one call to sqlite3_exec then it > won't suffer from

Re: [sqlite] threads and last_insert_rowid()

On Tue, Nov 16, 2010 at 04:08:16PM +0300, Ruslan Mullakhmetov scratched on the wall: > i got following contradictory replies to my question > > > if i execute query like " insert into tbl( filed ) VALUES ( 1 ); Select > > last_insert_rowid() as li;" would be it atomic? or it anyway would

Re: [sqlite] threads and last_insert_rowid()

On Tue, Nov 16, 2010 at 11:38 AM, Ruslan Mullakhmetov < r.mullakhme...@tools4brokers.com> wrote: > > Understand this: Any programming language that is built around threads > is > > inherently broken and should be avoided. (I will not name names - you > know > > the languages I'm talking about.)

Re: [sqlite] threads and last_insert_rowid()

> Understand this:  Any programming language that is built around threads is > inherently broken and should be avoided.  (I will not name names - you know > the languages I'm talking about.)  And any operating system that depends > upon threads for performance is equality busted and should also be

Re: [sqlite] threads and last_insert_rowid()

On Tue, Nov 16, 2010 at 10:29 AM, Ruslan Mullakhmetov < r.mullakhme...@tools4brokers.com> wrote: > > as you see in _serialized_ mode "SQLite can be safely used by multiple > threads with no restriction". > > do i misunderstand something? > With serialized threading, SQLite is perfectly "safe" to

Re: [sqlite] threads and last_insert_rowid()

thanks everybody, especially Pavel Ivanov who did not give himself a trouble to look at the source though i did. but as far as i understand this is only applicable to current version of sqlite and future releases may change things. Jay A. Kreibich wrote: > If each thread is using its own,

Re: [sqlite] threads and last_insert_rowid()

> whom to trust? Trust Kees. Borgan's thought about keeping the lock and transaction management inside sqlite3_exec is incorrect. > as for Kees Nuyt reply, did you toke int account that "select > last_insert_rowid() " > and insert query combined in single query and executed via single call > of

Re: [sqlite] threads and last_insert_rowid()

i got following contradictory replies to my question > if i execute query like " insert into tbl( filed ) VALUES ( 1 ); Select > last_insert_rowid() as li;" would be it atomic? or it anyway would suffer > from threads? from borgan: > Hi, i think this will probably be "atomic". > What i mean

Re: [sqlite] threads and last_insert_rowid()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/2010 04:15 AM, Ruslan Mullakhmetov wrote: > i need to get last insert id in multithreaded app. > I use C API, actually some C++ wrap over it. > if i execute query like " insert into tbl( filed ) VALUES ( 1 ); Select > last_insert_rowid() as

Re: [sqlite] threads and last_insert_rowid()

On Mon, 15 Nov 2010 15:15:10 +0300, Ruslan Mullakhmetov wrote: >hi. > >i need to get last insert id in multithreaded app. >I use C API, actually some C++ wrap over it. >if i execute query like " insert into tbl( filed ) VALUES ( 1 ); Select >last_insert_rowid()

Re: [sqlite] threads and last_insert_rowid()

Hi, i think this will probably be "atomic". What i mean is the transaction will aquire EXCLUSIVE lock (because of the insert command) and it will keep this lock until commit, which takes place after the last select and last semicolon. So i believe no other threads should be able to do anything