Interesting. Why does the client need to know the id of the shard on which the object resides? I'm sure you have a good reason, I'm just curious.
There's a method available on ShardedSession that will, given an object that is known to some Shard, return the ShardId: ShardedSession.getShardIdForObject(). You can call this on the serverside and set its return value as a transient property on the objects that you ship to the client. The trick for you, I suspect, will be putting the code to do this in a centralized location so that you don't need to remember to populate this value every time. An Interceptor sounds like a fine idea. It's true that the Interceptor methods don't give you access to the Session (and even if they did it would probably be the real Session, not the ShardedSession). Do you store your ShardedSession in a ThreadLocal that you could access from within the Interceptor? You might also take a look at this feature request that was filed:
http://opensource.atlassian.com/project ... /HSHARDS-9
The filer proposed adding a ShardAware interface and having an ExitStrategy that then adds the id of the shard on which the object was found to all objects that implement this interface. I'm not sure how I feel about this but maybe it will inspire you.
Max