In order for this use case to be truly atomic, you need a distributed cluster-wide lock. JBoss Cache does not yet support an option for distributing locking (instead locks are acquired when applying remote transaction batches), mainly because distributed locking does not scale very well, and is overkill for most use cases. However, it is on the roadmap. Please vote on it if this is important to you so that we understand the demand and can plan accordingly. http://jira.jboss.com/jira/browse/JBCACHE-1098 In the meantime you have some other options: | * If your cluster shares a DB already, then use it's native sequence, or if it doesn't have one use "select for update" to serialize access to a column | * Ensure that only one node is used for this operation. If that node fails, you can then failover to another node, and ensure that all subsequent operations are against this node. | * Use the jboss HA Singleton service (this however would be vulnerable to cluster splits [each splitoff would end up with its own singleton until the cluster heals) | * Use jgroups to write your own sequence protocol. This wouldn't be too complex. You would be able to handle the split condition by incrementing the counter by some large amount when the coordinator changes, and then reconcile the counter state on merge | -Jaosn View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4076466#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...