If you're using a client side singleton facade to the session bean, I don't know why synchronized access to all of the methods would be a bad thing. It should prevent the problem entirely, assuming it performs well enough (different issue entirely).
The core problem is simply that you have to have synchronous access to the SFSB.
Catching and retrying on the ConcurrentException is simply a mechanism to handle the conflicts, but I don't see how it gains anything, really, over a synchronized facade to the SFSB on the client side.
The painful part is that you have to eat the synchronous costs not just for the method call, but also for the transport of the data when it's not really important any more.
If you're moving any real amount of data, that's where the synchronous impact hurts the most.
Now, something you might want to try would be to have a synchronization map on the server side, and facade the SFSB with a normal Stateless SB.
The game here is that you pass the SFSB handle around with your other data. The SSB gets the handle, grabs a locking object from a cache based on the handle, and uses that object as a semaphore to synchronize access on the server side to the SFSB.
The nice part of this is tho, that your SFSB is only blocked while it's actually processing, and not stuck for actual I/O with the client.
A contrived example is this.
Say you have a "getCustomers" method on the SFSB. And say that this method sends enough data that it take .5 sec to send the actual data to the client. Just the physical transport time.
Normally, anyone wanting to access that SFSB is stuck waiting for that .5 sec until the data is moved over. As long as data is being serialized, you're still "accessing the SFSB", so it's vulnerable to the ConcurrentAccess issue. And if you're using a synchronized facade, all of the other methods are blocked waiting for the method to return, which is waiting for the data.
Now, consider using the SSB facade. Here we assume the SSB is local to the SFSB (other wise this is basically pointless). The SSB calls the SFSB, SFSB processes and creates its list of results, and then returns that list (as an ArrayList, say) to the caller, the SSB. Since it's a local call, that return is instantaneous (it's just a object pointer after all). At this point, you're no longer accessing the SFSB, the SFSB is "free" to do other work. Now, the SSB takes the .5 sec hit of downloading the data, while other methods are off on their merry way with access to the SFSB.
You may have to play some games with transactions (I don't know exactly when an SFSB get "freed up" so it can play with others, whether it's simply physical access to the bean, or whether it's at transaction commit).
But if you have other, say, finer grained methods that are blocked by methods with larger payloads, this could be a mechanism to improve throughput since the synchronous SFSB is never waiting on client I/O.
[Message sent by forum member 'whartung' (whartung)]
http://forums.java.net/jive/thread.jspa?messageID=239911