I'm thinking of something which can be swapped in place of the Pessimistic/OptimisticLockInterceptor (DistPess/OptLockInterceptors?) which in addition to obtaining local locks, uses a methodcall broadcast to replicate lock() methodcalls up remote stacks.

Not the most efficient since this will have all sorts of scalability problems, but at least it gives us an initial impl of distributed locking in JBC.

Later, more sophisticated mechanisms could include awareness of partitions and buddy groups, and only replicate the lock call to nodes which are known to have the state.

Also, maybe Terracotta's client-server mechanism for dealing with distributed locks (ugly cos it's client svr) may be more efficient?

I'm not a fan of exposing locking behaviour so explicitly. Internally, a sequence of calls like:

tx.begin();
cache.put("/session/123");
cache.put("/session/123/abc")
cache.put("/session/123/xyz")
tx.commit();

Agreed. Ok, maybe an early impl like that could be quite feasible. Won't be something like Terracotta's intercepting synchronized blocks on the JVM level and performing similar "remote" synchronizations via their "hub", but a more specific scenario focused on locking nodes in the cache based on our existing lock strategies.