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 m
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
On May 25, 12:06 am, PierreW wrote:
> Hi guys,
>
> I have been trying to access session data (I am using the
> ActiveRecordStore option) from a background process (Workling in my
> case - but I suspect it should be the same for others). It seems to me
> it should be fairly obvious since I can pa
A couple of problems that jump out regarding accessing/using session
data in that strategy you outlined:
- the background threads/processes might end up using invalid session
data if the session data changes during the time from when you pass in
that session_id and when some background thread/pro
Jeff, thanks a lot.
Just one thing though: if I do this, does it mean I am taking the
session data "out of" ActiveRecord? I was thinking that by only
passing the session ID and by letting the worker retrieve the record
in the DB, consistency would be guaranteed by ActiveRecord. But maybe
I am gett
How about just passing in the session data hash when you call the
particular workling ob method, something like:
### in ./app/workers/foo_worker.rb
class FooWorker < Workling::Base
def bar(options)
session_data = options[:session_data])
# do something with session.data hash ...
6 matches
Mail list logo
