@Override
  public Long expire(final byte[] key, final int seconds) {
    checkIsInMultiOrPipeline();
    client.expire(key, seconds);
    return client.getIntegerReply();
  }
@ Override public Long expire ( final byte [ ] key , final int seconds ) { checkIsInMultiOrPipeline ( ) ; client . expire ( key , seconds ) ; return client . getIntegerReply ( ) ; }
Set a timeout on the specified key. After the timeout the key will be automatically deleted by
the server. A key with an associated timeout is said to be volatile in Redis terminology.
<p>
Volatile keys are stored on disk like the other keys, the timeout is persistent too like all the
other aspects of the dataset. Saving a dataset containing expires and stopping the server does
not stop the flow of time as Redis stores on disk the time when the key will no longer be
available as Unix time, and not the remaining seconds.
<p>
Since Redis 2.1.3 you can update the value of the timeout of a key already having an expire
set. It is also possible to undo the expire at all turning the key into a normal key using the
{@link #persist(byte[]) PERSIST} command.
<p>
Time complexity: O(1)
@see <a href="http://redis.io/commands/expire">Expire Command</a>
@param key
@param seconds
@return Integer reply, specifically: 1: the timeout was set. 0: the timeout was not set since
the key already has an associated timeout (this may happen only in Redis versions &lt;
2.1.3, Redis &gt;= 2.1.3 will happily update the timeout), or the key does not exist.