问题
I use spymemcached 2.6rc1 in my Java project where I want to use the Long class as a storable object. Unfortunately, when I store e.g. new Long(0) object, the get(...) and incr(...) give the wholly different results - get gives Long object that contains 48 value and incr gives 1. Please note that 48 represents the ASCII "0" symbol. When I try to get the value for the same key directly from memcached (e.g. by using telnet) I get the correct result - 0. Strange, the Long is good serialized class. So, probably, there is some problem with default transcoding. Can somebody clarify how to resolve this situation?
回答1:
There was an issue filed for this a while back (spymemcached bug 41). Here's what Dustin Sallings, the creator of Spymemcached said about the issue:
You can't mix IntegerTranscoder and incr/decr. incr/decr require the numbers to be encoded as strings as they are language-agnostic server-side operations.
Here's a unit test that demonstrates what you're trying to do:
public void testIncrDecrBug41() throws Exception {
final String key="incrdecrbug41";
// set to zero
client.set(key, 86400, "0");
// retrieve it to see if it worked
assertEquals("0", client.get(key));
// increment it
assertEquals(1, client.incr(key, 1));
// fetch it again to see if it worked
assertEquals("1", client.get(key));
}
Note that the reason you get 49 is because decimal 49 is the string "1".
incr and decr cause a lot of confusion for people because of the server-side semantics. In newer version of memcached (e.g. changes I don't have applied yet in my binary branch), incr and decr will fail on non-numeric string values. That is, your first incr would throw an exception.
In the future please file bugs at the Spymemcached project website. It can be found at http://code.google.com/p/spymemcached. That way we can fix them sooner.
来源:https://stackoverflow.com/questions/5928964/spymemcached-get-and-incr-methods-give-wholly-different-results