Hi, it is legal to have both local and remote interfaces to the same bean. Though the book says it does not make sense. Let's say we have both interfaces for entity bean. I chose entity because all clients will share the same bean object (through different EJBObject objects) if and if the primary key (the entity itself) is the same. Let's say bean represents person 'Smith'. Now if we have 2 interfaces to our entity bean and 2 clients (remote and local). If remote client request access on 'Smith' and local client requests access for 'Smith' will they get to the same bean? Same bean class of course, but will it be 1 object or 2 objects. Could this lead to synchronization problems? I guess they will have different EJBObject's (local and remote) which in entity bean case is one step to disaster. So I am afraid that will not work well. The book gives an excercise "Given a remote client 'R', that has valid references to session beans 'A' and 'B', and given that A is local to B, which statements are true? Amongst others I chose: A. R cannot pass his reference for A, to B. The correct answer is R CAN pass his ref for A to B. So here is my question: doesn't this question implies that A have both local AND remote interfaces. Which I came to conclusion (AM I WRONG?) will never ever point to the same bean object and is the source of evil.
AFAIK, you can have local and remote references to the same bean. Both of them deal with the same instance. Concurrency is controlled by the server. Current opinion is that entity beans as a general rule should not be exposed to remote clients. [ December 04, 2003: Message edited by: Rufus BugleWeed ]
Joined: Dec 02, 2003
Heh, I am afraid I am gonna get something like that in exam. I don't really understand how this work. And currently I dont see any reason to make local beans too. I think the performance gain from that would be maybe 10%, depends on what you do. But it compromises scalability and reusability of beans.
Originally posted by Vladas Razas: Heh, I am afraid I am gonna get something like that in exam. I don't really understand how this work. And currently I dont see any reason to make local beans too. I think the performance gain from that would be maybe 10%, depends on what you do. But it compromises scalability and reusability of beans.
10%? Think about an entity bean with ten attributes. Using the remote interface to retrieve all ten attributes will have a larger performance impact over the local interface than 10% I'd bet. For larger business methods, yes, the performace gain of local interfaces is not as much, but for accessing entity beans I wouldn't have it any other way. In fact, I expose *only* the local interface for entity beans and both local and remote interfaces for session beans.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com
subject: EJB entity beans with both local and remote interface