Backgroundrb devel - Jul 2006 - Very strange after_save problem. Please help.

I have a very strange problem here. I do not get this. So any help is  
greatly appreciated.

Basically I have a model that calls a method in the background  
process in the "after_save" method. Let''s call the model
products. So
what happens is this:

1. I create a new product.
2. Everything works and the product is saved with id 13.
3. A method is called in my background process passing it the NEW  
product id in the after_save method.
4. That method in the background process says "Can''t find Product
with id=13".
5. An exception is then passed back to my after_save method and the  
product rolls back like adding it never happened. Because when an  
exception is raised in after_save it rolls back.

So I figured maybe it wasn''t connecting to the database or something.  
I adding a product in the db manually and added the following in my  
backgroundrb method:

p = Product.find_all
raise p.inspect

I try to add another product and it shows me that product I just  
added into the database manually but not the one that was just  
created through the product model. So the backgrond process is  
connecting to the database.

So in my after_save method i did the following to make sure it was  
getting into the database:

p = Product.find id
raise p.inspect

I tried to add a product again and it raised an exception with the  
product information that I JUST added.

Why is backgroundrb not seeing new additions to the database when  
being called from after_save? It''s like backgroundrb doesn''t  
acknowledge it''s existence until after_save is finished.

Anyways, if this is the case, is there a work around so that I can  
invoke a backgroundrb method on a freshly saved product?

Thanks a lot for your help.

Thank You,
Ben Johnson
E: bjohnson at contuitive.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060717/fb4082e8/attachment.html

On Jul 17, 2006, at 3:49 PM, Ben Johnson wrote:
> I have a very strange problem here. I do not get this. So any help  
> is greatly appreciated.
>
> Basically I have a model that calls a method in the background  
> process in the "after_save" method. Let''s call the model
products.
> So what happens is this:
>
> 1. I create a new product.
> 2. Everything works and the product is saved with id 13.
> 3. A method is called in my background process passing it the NEW  
> product id in the after_save method.
> 4. That method in the background process says "Can''t find
Product
> with id=13".
> 5. An exception is then passed back to my after_save method and the  
> product rolls back like adding it never happened. Because when an  
> exception is raised in after_save it rolls back.
>
> So I figured maybe it wasn''t connecting to the database or  
> something. I adding a product in the db manually and added the  
> following in my backgroundrb method:
>
> p = Product.find_all
> raise p.inspect
>
> I try to add another product and it shows me that product I just  
> added into the database manually but not the one that was just  
> created through the product model. So the backgrond process is  
> connecting to the database.
>
> So in my after_save method i did the following to make sure it was  
> getting into the database:
>
> p = Product.find id
> raise p.inspect
>
> I tried to add a product again and it raised an exception with the  
> product information that I JUST added.
>
> Why is backgroundrb not seeing new additions to the database when  
> being called from after_save? It''s like backgroundrb
doesn''t
> acknowledge it''s existence until after_save is finished.
>
> Anyways, if this is the case, is there a work around so that I can  
> invoke a backgroundrb method on a freshly saved product?
>
> Thanks a lot for your help.
>
> Thank You,
> Ben Johnson
> E: bjohnson at contuitive.com

Hey Ben-

	I''m not 100% certain but what I think is happening is that since the  
after_save is run inside the transaction for that save, the new item  
is not commited to the db because the after_save is failing. Now i  
think whats happening is that since the save has not been commited in  
rails yet, it isn''t actually in the db yet so your background worker  
cannot see it yet.

	I think that instead of trying to do this in after_save that maybe  
you should put the call to your background worker in an AR Observer  
that runs the background task *after* the save has been commited.  
Basically I think you are short circuiting yourself becazsue the  
record is not saved to the db until the transaction is commited but  
your drb task cannot find that record until after it is commited.  
Make any sense?

-Ezra


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20060717/f3266cb0/attachment-0001.html

On Jul 18, 2006, at 6:54 AM, Christian Romney wrote:
> Hi all,
> I''m looking for a little deployment guidance. I have a webfarm
with
> two app servers running rails that need to make use of BackgrounDRb.
> I presume I should have a single machine running backgroundrb,  
> since otherwise we would run the chance of a client switching  
> servers and polling for a non-existent job.
> Assuming I need to change the backgroundrb.yml file on the two app  
> servers to point to an instance running on some third machine, I''m
> a little lost on what each config should look like.
> (The config on the app servers vs. the config on the drb server).  
> Any guidance is much appreciated. Alternatively if there''s an  
> effective way to "cluster" backgroundrb instances and maintain a
> global, shared keyspace (thinking of Mogilefs, for instance) I''d  
> welcome suggestions as well.
>
> Thanks for releasing such a great tool!
> Christian Romney
>
Hey Christian-

	Yeah you will want to run the drb server one either one of the two  
app servers or a third box depending on your setup. THe way things  
work is that backgroundrb is tied to your rails app so if you run it  
on a third box you will still need to check out a copy of your app  
onto that third box. You just wont run the rails app part of it and  
only the drb server. In the config file you will need to set your IP  
addresses and your acl lists correctly.

Here is a config file. You will want to change probably the port  
number, the IP address and the acl list. Lets say you will run the  
drb server on 192.168.0.3 and your two app servers are 192.168.0.1 &  
192.168.0.2.

---
port: "22222"
timer_sleep: 60
load_rails: true
environment: development
host: 192.168.0.3
database_yml: config/database.yml
acl:
   deny: all
   allow: localhost 127.0.0.1 192.168.0.1 192.168.0.2
   order: deny,allow


You will need to make sure that the backgroundrb.yml config file is  
the same in all three places so they all point to the same drb server.

As far as clustered drb servers, that is something I do plan on  
tackling but probably not for another month or so. I plan on setting  
up a distributed worker pool using Rinda and tuplespace to have a  
pool of backgroundrb processes available at any one time.


-Ezra