initial incr call

[Cahill, Earl]

Looks like this works, without the need for the lock

 

sub incr {

  my $self = shift;

  my $key = shift;

  my $value = shift || 1;

  unless($self->SUPER::incr($key, $value)) {

    $self->add($key, 0);

    $self->SUPER::incr($key, $value);

  }

}

 

Thanks to Patrick for pointing me to ->add.

 

Earl

 

  _____  

From: Cahill, Earl 
Sent: Friday, March 18, 2005 9:41 AM
To: memcached at lists.danga.com
Subject: initial incr call

 

Probably been over this before, but the initial incr call seems kind of
strange to me.  Let's say I have a new key called counter, and I want to
incr it.  I call $memd->incr('counter'); and get undef back.  So, I set it
to 0, and then if I call incr, happy day.  The problem is that setting to 0
is a total race condition, so I have to do something like this

 

sub incr {

  my $self = shift;

  my $key = shift;

 unless($self->get($key)) {

    require File::NFSLock;

    my $lock = File::NFSLock->new("$nfs_path/memcache.incr.$key",
"BLOCKING", 15, 10);

    if($lock) {

      $self->set($key, 0);

    }

  }

  $self->SUPER::incr($key);

}

 

where you lock however you like.  Maybe it's too late now, but it sure seems
like it would be nice if the server would some do similar thing.  I would
like to just call incr, regardless of whether the key has existed before or
not, and get back either 1 for new values, or the old value plus one.  Is
there a reason incr behaves as it does?

 

Earl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20050318/e15938bf/attachment.html