Dain Sundstrom wrote:The reflective mapping is build inside the running container on the server side during startup and is private to the container. Clients never see it, so you have nothing to worry about.
When looking for speed ups, we may potentially remove some of the loose coupling to obtain the speed. The EJB method is invoked by the client and this is marshalled by the server to perform the EJB method. A client implementation of the EJB interface is required to request the server to perform the method on the pooled EJB method. Looking at the worst case, Remote , we need to identify the method invoked which must be done in a serialised manor.
There are a bunch of common methods (equals, isIdentical, getPrimaryKey) that can be handled on the client directly.
Chris Nokleberg wrote:Since the set of keys is fixed, it actually is possible to generate code
faster than a generic hash map.
Thus as there is a fixed number of methods possible, we could ultimately define each method (including overriden methods) with an ordinal integer. On this number we could then provide the method mapping through code generation - a switch statement. The solution is still transparent to the client as it is contained within the Stub. Potentially we can reuse this for Local interfaces also. The code generation can also provide hooks in for the appropriate security and transaction requirements.
Already got that one... That is the way the remoting framework is implemented today.
-dain
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
