Jeremy Evans wrote:
> On Jul 13, 4:41 pm, Joel VanderWerf <[email protected]> wrote:
>> What does the "thread safety" of sequel actually mean?
>>
>> The following code has two threads write to a sqlite database inside
>> transactions, but the db gets locked in the middle of the first thread's
>> transaction, and then neither thread can proceed. Aren't transactions
>> atomic wrt ruby threads?
>
> They are. The problem is with SQLite, not with Sequel. You must be
> using using too small a timeout (seems odd considering the timeout you
> are using and the amount of time you are sleeping, but that's my best
> guess). Really, for multithreaded write access on SQLite, you should
> use a :max_connections=>1 option so only one thread attempts to access
> the database at once. Really, you should avoid using SQLite
> altogether in such situations (see http://www.sqlite.org/whentouse.html).
They do list "high concurrency" as a situation that might point to using
another db, but I hardly thought of my example as that.
Yeah, I'm slowly getting the point about sqlite... I know there are
inherent limits in embedded dbs, having been the junior of two
developers on NeoAccess back in the late 90s. But one of my projects was
to make NeoAccess perform very fast and reliably under high thread load
even on smp systems (these were native threads, of course; the
concurrency constructs were based on atomic add instructions). NeoAccess
was what Netscape Communicator used for its address book, btw.
--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
