what i need:
if :record is in the database -> upgrade his counter
else create :record (with his counter on 1)
this should be done with an atomic operation, to avoid race
conditions.
What is the best way to do this with activerecord?
I read about transactions, but as i understand a transaction acts on a
single connection to the database.
<eugenio.mode...@gmail.com> wrote:
> what i need:
> if :record is in the database -> upgrade his counter
> else create :record (with his counter on 1)
> this should be done with an atomic operation, to avoid race
> conditions.
> What is the best way to do this with activerecord?
> I read about transactions, but as i understand a transaction acts on a
> single connection to the database.
incrementing the counter is simple enough - AR's increment_counter
method basically does update foos set counter = counter + 1 where ...
To avoid duplicate records being created I'd create a unique index on
whatever it is that identifies a record
eugenio.mode...@gmail.com wrote: > what i need: > if :record is in the database -> upgrade his counter > else create :record (with his counter on 1)
> this should be done with an atomic operation, to avoid race > conditions. > What is the best way to do this with activerecord? > I read about transactions, but as i understand a transaction acts on a > single connection to the database.
This would be a single DB connection, so it seems like a good candidate for a transaction. What's the problem with doing that?
On Nov 8, 6:50 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas-
s.net> wrote:
> This would be a single DB connection, so it seems like a good candidate
> for a transaction. What's the problem with doing that?
i think that multiple requests use multiple db connections, didn't
they? This is obviously true having two database server in a multi-
master configuration. I think that Frederick Cheung's solution should
solve the problem anyway.
thank you.
eugenio wrote: > On Nov 8, 6:50 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas- > s.net> wrote: >> This would be a single DB connection, so it seems like a good candidate >> for a transaction. What's the problem with doing that? > i think that multiple requests use multiple db connections, didn't > they?
Of course. But you shouldn't need a transaction over multiple requests; just encapsulating the INSERT and counter increment in a transaction, within a single request cycle, should do the trick.
> This is obviously true having two database server in a multi- > master configuration.
Well, that's just asking for trouble. :)
> I think that Frederick Cheung's solution should > solve the problem anyway. > thank you.
|
