# Multiple instances adding to the same attribute

**URL:** <https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459>\
**Category:** Rails\
**Created:** [June 10, 2007, 9:13pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459 "2007-06-10T21:13:52Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 10, 2007, 9:13pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/1 "2007-06-10T21:13:52Z")

</div>

Is there a possibility, when for example, counting a certain request,  
that a highly coincidental retrieval of information by two clients will  
override eachother’s contributions? Suppose you have:

counter +=1  
counter.save

If another request gets the initial counter value before the first one  
had time to save, and then the first one saves, then the second one  
saves, the counter is only updated by 1 instead of 2.

Does rails somehow protect itself from this kind of possibility? To be  
honest I’m not particularly familiar with server side applications, do  
they run in parallel or do they always finish processing the first  
request before serving the next?

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 10, 2007, 9:37pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/2 "2007-06-10T21:37:03Z")

</div>

You could do (and don’t quote me on this as I haven’t used it):

def fileserve  
file = Client.file.find(:first, …)  
respond\_to |format|  
format.zip {  
# send file here, not a link but a real file  
}  
end  
end

Sorry for my obscurity in the answer, don’t know how else to explain it.

That should work though I reckon. Never used respond\_to for anything  
but rails files though.

Cheers,  
Zach I.  
→ Blog – [http://www.zachinglis.com](http://www.zachinglis.com)  
→ Company – [http://www.lt3media.com](http://www.lt3media.com)  
→ Portfolio – [http://portfolio.zachinglis.com](http://portfolio.zachinglis.com)

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 10, 2007, 10:07pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/3 "2007-06-10T22:07:08Z")

</div>

Maybe you can use the optimistic locking. In rails, Optimistic locking  
is  
enabled by default on any table that contains an  
integer column called lock\_version. Then, you can handler the exception  
yourself or just discard it depend to your project.

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 10, 2007, 11:29pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/4 "2007-06-10T23:29:19Z")

</div>

Michael,

Sorry about that. I got a bounce from the group and reposted it under  
my other account. I misposted it to you.

Apoligies.

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 11, 2007, 1:22am UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/5 "2007-06-11T01:22:28Z")

</div>

Michael C. wrote:

> saves, the counter is only updated by 1 instead of 2.
> 
> Does rails somehow protect itself from this kind of possibility? To be  
> honest I’m not particularly familiar with server side applications, do  
> they run in parallel or do they always finish processing the first  
> request before serving the next?

A Rails process currently serializes requests, so there is no problem  
unless you run multiple Rails processes to increase server capacity.

But this is done very commonly, so you should allow for concurrency by  
instead writing counter updates directly to the database:

```
model = Model.find(:first)
Model.increment_counter(:counter, model.id)

```

–  
We develop, watch us RoR, in numbers too big to ignore.

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 10, 2007, 10:55pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/6 "2007-06-10T22:55:54Z")

</div>

Zach, I’m really not sure how that could help in my case 🙂

sishen wrote:

> Maybe you can use the optimistic locking. In rails, Optimistic locking  
> is  
> enabled by default on any table that contains an  
> integer column called lock\_version. Then, you can handler the exception  
> yourself or just discard it depend to your project.

I’ve heard about that. It’s intended to be used when multiple processes  
have access to a database simultaneously, the problem here is I’m not  
sure if in the typical scenario multiple processes do have access to the  
database simultaneously or whether it’s all serialized by default so no  
overlapping can take place. I suppose the question should be whether  
rails is or isn’t parallelized, and if it can be whether that’s  
something automatic or configureable.

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 11, 2007, 1:09pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/7 "2007-06-11T13:09:43Z")

</div>

Michael C. wrote:

> Would model.update\_attribute(:counter, model.counter+1) maintain the  
> same concurrency as your increment\_counter class method? Wouldn’t the  
> increment\_counter method itself implement update\_attribute?

No.

update\_attribute uses the in-memory Ruby counter value, which  
may be stale.

increment\_counter reads and increments the database value.

update\_attribute can however be safe if you’ve obtained  
the right table locks.

–  
We develop, watch us RoR, in numbers too big to ignore.

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 11, 2007, 11:58am UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/8 "2007-06-11T11:58:13Z")

</div>

Mark Reginald J. wrote:

> But this is done very commonly, so you should allow for concurrency by  
> instead writing counter updates directly to the database:
> 
> ```
> model = Model.find(:first)
> Model.increment_counter(:counter, model.id)
> 
> ```

Would model.update\_attribute(:counter, model.counter+1) maintain the  
same concurrency as your increment\_counter class method? Wouldn’t the  
increment\_counter method itself implement update\_attribute?

---

<div class="post-metadata">

**Author:** ![mcampbell](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/8e7dd6/32.png) [@mcampbell](https://www.ruby-forum.com/u/mcampbell)\
**Post date:** [June 11, 2007, 1:52pm UTC](https://www.ruby-forum.com/t/multiple-instances-adding-to-the-same-attribute/106459/9 "2007-06-11T13:52:20Z")

</div>

Mark Reginald J. wrote:

> update\_attribute uses the in-memory Ruby counter value, which  
> may be stale.
> 
> increment\_counter reads and increments the database value.
> 
> update\_attribute can however be safe if you’ve obtained  
> the right table locks.

Ah, alright. I thought increment\_counter was a custom defined class  
method you just used as an example, I just checked the rails docs.

Much thanks.