Skip to main content

Space Move aka poor man space transactions

· 2 min read
Alejandro Revilla

When we call:

   Object obj = sp.in ("MyQueue");
...
....
// do some processing using 'obj'
...
...

I always feel worried about what could happen between the point in time you take the object off the Space and you place it in a safe storage for further processing. There's always some single point of failure toward the outer services, for instance, while you are reading a message from a socket, if that process dies, your message is lost, but in the case of a Space, specially a reliable one (such as the VoldemortSpace), it's just too sad to loose a message that was previously carefully stored in a highly available fail-safe way, just because a client worker crashes. The initial solutions that came to mind would involve passing around some kind of Transaction Object (like Jini's Transaction or JTA) so we could make the Space participate in the transaction, but that's something easy to say, but not that easy to implement. Then sometime ago, I've read about how Amazon's SQS nicely solves a problem like this with temporary reads, when you read from SQS, you get the object for a couple of minutes and you need to confirm that you actually got it, otherwise, the object would show up again in the queue. I think an easy way to implement that using very simple space operations, would be to implement a temporary 'move' operation. I think that a proper syntax would be something like this:

   K move (K from, long timeout);

You get the idea, you'd use something like:

  Object tmpKey = sp.move ("MyQueue", 60000L);
try {
Object value = sp.rdp (tmpKey);
...
... process the entry
} finally {
sp.inp (tmpKey);
}

If for some reason, you fail to 'inp' from tmpKey in your 60 seconds time-window, the object would show up again in the 'MyQueue' queue. I'm not implementing this now, but I may add the method as a place holder in the Space interface.