Ruby Forum Ruby on Rails > ActiveRecord Sqlite Synchronization

Hey!

I'm using ActiveRecord with an SQLite Database.

It works great, but has one drawback. SQlite does'nt support multiple
connection at one time.

Is there a mathod to synchronize ActiveRecord calls over different
threads?

thx CK

google for activerecord multi threaded
I think it has something to do with allow_concurrency.
-R

On Mon, May 5, 2008 at 6:47 AM, Christian Kerth

Roger Pack wrote:
> google for activerecord multi threaded
> I think it has something to do with allow_concurrency.
> -R
> 
> On Mon, May 5, 2008 at 6:47 AM, Christian Kerth

Hmmm doesn't work form me. I still get a "busy-Exception".

Other options?

thx

allow_concurrency "allows conconcurrency" on the connection (as
opposed to the database), so 2 threads can execute on the same
connection.  If you're trying to have 2 applications read from the
same database (like having a script/runner do database stuff in the
background while your server runs), this is simply not possible.
Because SQLite effectively uses a flat-file, there is no way to have
more than 1 connection to the same database -- there is no way for one
connection to know what the other is doing so as to avoid concurrent
modifications resulting in data corruption.


On May 5, 9:39 am, Christian Kerth <rails-mailing-l...@andreas-s.net>

tekwiz wrote:
> allow_concurrency "allows conconcurrency" on the connection (as
> opposed to the database), so 2 threads can execute on the same
> connection.  If you're trying to have 2 applications read from the
> same database (like having a script/runner do database stuff in the
> background while your server runs), this is simply not possible.
> Because SQLite effectively uses a flat-file, there is no way to have
> more than 1 connection to the same database -- there is no way for one
> connection to know what the other is doing so as to avoid concurrent
> modifications resulting in data corruption.

i would need a queuing mechanism, that executes queries fifo.

Wouldn't it be possible to achieve such a behaviour with a mutex, that 
synchronizes access to activerecord's save and destroy methods?

ck

On 5 May 2008, at 16:56, Christian Kerth wrote:

>> connection to know what the other is doing so as to avoid concurrent
>> modifications resulting in data corruption.
>
> i would need a queuing mechanism, that executes queries fifo.
>
> Wouldn't it be possible to achieve such a behaviour with a mutex, that
> synchronizes access to activerecord's save and destroy methods?

Not if you're talking about separate mongrels (or rails instance of
any sort). But doesn't sqlite allow enough concurrency 
(http://www.sqlite.org/lockingv3.html
) ?

Fred

Frederick Cheung wrote:
> On 5 May 2008, at 16:56, Christian Kerth wrote:
> 
>>> connection to know what the other is doing so as to avoid concurrent
>>> modifications resulting in data corruption.
>>
>> i would need a queuing mechanism, that executes queries fifo.
>>
>> Wouldn't it be possible to achieve such a behaviour with a mutex, that
>> synchronizes access to activerecord's save and destroy methods?
> 
> Not if you're talking about separate mongrels (or rails instance of
> any sort). But doesn't sqlite allow enough concurrency 
> (http://www.sqlite.org/lockingv3.html
> ) ?
> 
> Fred

I have one Ruby Process, that runs two threads.

In one of them runs a webrick server, one is a background task. Both 
threads operate on the same database.

I've done a quick prototype with a mutex and i seems to work; no more 
busy exceptions.

I still have to dig a bit deeper.

Yes, your fifo/mutex concept is correct.  You just have to ensure that
2 active record instances don't attempt to play with the database at
the same time.

On May 5, 11:06 am, Christian Kerth <rails-mailing-l...@andreas-s.net>

You are correct that SQLite3 does provide "enough" concurrency;
however, the active record decides to pitch a hissy-fit, throwing
exceptions, when it encounters a locked db rather than waiting and
trying again for a certain period.

On May 5, 11:01 am, Frederick Cheung <frederick.che...@gmail.com>