Ruby on Rails

Not sure what you are attempting to accomplish in those background
threads/processes, or what the reasoning is behind even using multiple
background threads/processes in the first place in light of what you
seem to be trying to do, but the basic strategy you're attempting to
pursue where you have multiple concurrent threads/processes all
reading from and writing back to some user's session data is just
asking for trouble on a number of levels: overwriting of data by one
of the background threads/processes or the user; resource contention
and deadlock; .....

Even if you didn't use the user's session data to work with / store
such data, if you really want/need to pursue this multi-thread/-
process strategy for processing some common data, then you better
design that processing to deal for concurrency issues, which is not a
simple task.

Other alternatives include bailing entirely on the background threads/
processes and just perform the data processing sequentially and reset
the final val(s?) in the user's session once processing is completed,
or you could pass off such sequential processing to be done in some
background process that performs that data processing sequentially in
that background process and persists the final results somewhere else
to be picked up later on and made available to the user in some future
request.

Jeff

On May 26, 1:35 pm, PierreW <wamre...@googlemail.com> wrote:
> Fred and Jeff: thanks a lot I got it to "work".
>
> Thing is… I ran some tests and concurrency is in fact a big problem:
> my background workers all need to read and write from/to the session
> data. I was thinking that using a lock would help (each process would
> have to wait for the other to release the data):
>
> ActiveRecord::SessionStore::Session.find(:all, :conditions =>
> ["session_id = ?", lsession_id], :lock => true)
>
> but I am in fact getting an ActiveRecord::ConnectionTimeoutError (and
> yet I am trying to release the session as quickly as possible in each
> process).
>
> So I was wondering: is there a recommended design to get several
> workers to pass info between each other? Say for example:
>
> - a bunch of workers A do a simple task
> - a daemon worker B is "listening"
> - each time a process A returns a value, it "sends" it to B
> - B accumulates these values
>
> I thought that Workling return store would do the trick but it
> doesn't: each time you "set" a value it erases the previous one. I
> guess each A could store their return value as a row in a DB - but it
> seems to me like an overkill?
>
> For some reason I struggle to find info on this on the web.
>
> Thanks a lot,
> Pierre

--
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@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.