I was looking at your implementation and several things came to mind regarding locking and tx management.
Isn't it so that locking is provided by an interceptor, and that as far as EJB's go the locking is an 'aspect' that is taken care of before the persistence interceptor is reached? The locking manager in cooperation with the locking interceptor is responsible for the blocking of threads requesting objects with a locking policy.
The workings of the tx manager are still unknown to me, but I know that objects are locked on the basis of the tx id which was given to the thread that makes a call through the invokers, the tx is assigned by an interceptor too.
Couldn't a cache in JBoss thus just plainly implement the get and set methods, and leave the rest of the difficult stuff to different services?
What also came to mind was that for a distributed eviction policy based on the least recently used algorithm each get operation would have to broadcast an asynchronous message to let the others know the object is still being used.