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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 <rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> > 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 > -- > Posted via http://www.ruby-forum.com/. > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 KerthHmmm doesn''t work form me. I still get a "busy-Exception". Other options? thx -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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 > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 5 May 2008, at 16:56, Christian Kerth wrote:> > 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?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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 > ) ? > > FredI 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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...-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:> 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. > -- > Posted viahttp://www.ruby-forum.com/.--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On 5 May 2008, at 16:56, Christian Kerth wrote: > 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--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---