I will improve EJB2.X design Tomhornson # (at) #hotmai.com in Lushan EJB once the most shiny in J2EE technology, however, the time is moved, "EJB IS DEAD!", "EJB2.x is dead" Such an argument has been disconnected.
The quality of the technology is judged, often related to the judge itself, the technology is biased, and the project experience, etc. Therefore, often, we are not eligible, and there is no need to come to the argument of others.
Based on the understanding of the EJB specification, some kind of EJB IMPLEMENTS SOURCE is read and combined with some personal experience and thinking, the author tries to analyze the shortcomings of the EJB model and EJB IMPLEMENTS, and propose some improvement ideas.
Note: See the EJB SPEC is 2.1, 3.0.
Refer to Implements for JFOX-1.2, JBoss-2.4.5, JBoss-3.2.0, OpeneJB-0.9.2.
First, try to reduce the number of clients, server-side communication, and transmitted data
1. For services such as RMI as the underlying communication protocol, such as Naming Service's Locate, Naming Service, HOME object's REMOTE operation, etc., using custom connection management.
2. The client can dynamically add a variety of Interceptors. Such as transaction Interceptor, security interceptor, data compression interceptor, log interceptor, etc.
Second, improve Protocol
1, NIO to improve RMI.
Currently, RMI uses multi-threaded to solve the problem of blocking problems when the service is multi-client. Moreover, from the RMI Source, it can be seen that the use of RMI thread technology is too hot. We build a scenario: an REMOTE object can specify a specific port export. If not specified, it will be exported in the default Port. Each time a Remote object is exported, a new THREAD is generated, listening to a specific Port, and each monitoring is a Connect, a handling thread will also generate a THREAD. Imagine, even a small number of users will also cause the system thread volume to increase. The performance loss caused by the thread context switch is well known.
2. Improve the JNDI IMPLEMENT algorithm, data structure, etc. to improve performance. Improve the use of Naming Service through a series of EJB Pattern.
This is important because Naming Service is an extremely frequent service.
Third, improve the session bean service strategy
The SESSION bean is currently using multi-threaded, multi-bean services multi-client strategy. Note that more beans say this is to STATELESS SESSION bean. The stateful session bean, and the stateless session bean is different, the front-end call chain is: Customer-> stateful bean instance cache-> stateless bean instance Pool. A customer session is characterized by a specific STATEFUL BEAN.
TIP: Here for bean developers, setting the right cache size, the appropriate Pool Size is critical to performance improvement. Adjusting Size mainly prevents frequent Bean Persistence, causing the appearance of I / O bottlenecks. First, we think a few questions.
u Why do you multi-thread?
First, because the current RMI uses multi-threaded strategies, it can be said that the session bean is inevitably needed to use multithreaded strategies.
Second, the session bean can be blocked, in which case the session bean must adopt multi-threaded strategies.
v Why do you bean?
In order to disclose Bean developers from Thread-Safe program.
W Will be released from Thread-Safe program, can you use multiple threads, single bean service multi-client?
The answer is: No. Because Container-Managered Transaction is bound to threads. Single Bean will make this problem difficult to resolve.
Here, everyone can see that the most efficient service strategy is a single thread, single bean service multi-client. However, for possible beans that may block, multithreading strategies must be used.
So, what we can do is to specify a service policy based on whether the user can block, by the configuration file. There are two cases:
1. For blocking beans, use multithreaded, multi-bean service policies.
2. For non-blocking beans, use single-threaded, single Bean service policies.
And all of this is that RMI has been improved using NIO, otherwise, as we mentioned above, we can only use multi-threaded, multi-bean service multi-customer strategy.
X For this topic, in the end, I still have a problem. Currently, the RMI uses multi-threaded strategies, then Remote HOME objects, including Container, etc., from the perspective of EJB IMPLEMENT, should ensure its thread- Safe. However, I found that JFOX, JBoss has no related processing code, only a small amount of processing in OPENEJB.
Fourth, improve Entity Bean
The issue of Entity Bean is more complicated.
1. Entity Bean is also a multi-threaded, multi-bean service multi-client strategy.
Regarding this topic, my idea is basically the same as the answer to the corresponding problem in the session bean.
However, RD Roman believes that multi-threaded, multi-bean is the best service strategy. Of course, the premise of his discussion is based on the current RMI multi-threaded model, so it is necessary to discuss how bean is still a single bean to serve multiple customers. Multi-line BEAN Services multi-client, I have confirmed that it is not possible. Therefore, in general, my opinion is consistent with RD Roman's opinions, but I assume that I use NIO to improve RMI, which is not necessarily a multi-thread, and for non-blocking beans can use single-threaded, single bean service multi-customer strategy Yes.
Several Entity Bean Instances May Represent The Same Underlying Data
Let's consider the scenario in which many threads of execution want to access the same database data simultaneously. In banking, interest might be applied to a bank account, while at the same time a company directly deposits a check into that same account. In e- Commerce, Many Different Client Browsers May Be Simultaneously INTERACTING WITH MANY Clients Accessing The Same Data, We need to design a hightperformance
. Access system to our entity beans One possibility is to allow many clients to share the same entity bean instance; that way, an entity bean could service many client requests simultaneously While this is an interesting idea, it is not very appropriate for EJB,. For Two Reasons. First, IF WE'D LIKE AN
entity bean instance to service many concurrent clients, we'd need to make that instance thread-safe. Writing thread-safe code is difficult and error-prone. Remember that the EJB value proposition is rapid application development. Mandating that component vendors produce stable thread-safe code does not encourage this. Second, having multiple threads of execution makes transactions almost impossible to control by the underlying transaction system. For these reasons, EJB dictates that only a single thread can ever be running within a bean instance. With session Beans and Message-Driven Beans, AS Well As Entity Beans, All Bean Instances Are Single-Threaded.
Mandating that each bean can service only one client at a time could result in performance bottlenecks. Because each instance is single-threaded, clients need to effectively run in lockstep, each waiting their turn to use a bean. This could easily grind performance to a Halt in any large enterprise deployment.
To boost performance, we could allow containers to instantiate multiple instances of the same entity bean class. This would allow many clients to concurrently interact with separate instances, each representing the same underlying entity data. Indeed, this is exactly what EJB allows containers to do , Client Requests Do Not Necessarily, Butrather Concurrently.having Multiple Bean Instances Represent The Same Data Now Raises A New
problem:. data corruption If many bean instances are representing the same underlying data via caching (see Chapter 14), we're dealing with multiple inmemory cached replicas Some of these replicas could become stale, representing data that is not current..
To achieve entity bean instance cache consistency, each entity bean instance needs to be routinely synchronized with the underlying storage. The container synchronizes the bean with the underlying storage by calling the bean's ejbLoad () and ejbStore () callbacks, as described in the previous section .
The frequency with which beans are synchronized with an underlying storage is dictated by transactions, a topic we cover in Chapter 10. Transactions allow each client request to be isolated from every other request. They enable clients to believe they are dealing with a single in- Memory Bean Instances Are Behind The Scenes. Transactions. Transactions..
2. Improve the Entity Bean work model, Entity Bean work model, my performance problem is too significant.
We build a scenario: customer wants to change PrimaryKey's Name member variable of Person EntityBean for a specific value, then the sequence of operations raised by EJB IMPLEMENTS: (assuming to BMP). U Home Calls FindByPrimaryKey, HOME removes a bean instance from the stateless bean instance pool, execute the bean method EJBFindByPrimaryKey, access the database, check if the database has a record of PrimaryKey to the specified value, if any, return PrimaryKey. v Home calls EJBLOAD to load data from the database, and assign a value in the stateful entity bean, making it entity bean, enters Cache from pool. Finally, return a user to an EJBOBJECT.
W Customed this EJBOBJECT HANDLE's setName ().
The setName () method, call EjbLoad () to synchronize the database before the bean instance is active, and EJBStore () will be called again after the setName () method.
x Here, a simple change of a record of a field is completed. A total of four and the database interaction, n multiple times to the Bean Instance operation. You said that this model, there is no performance problem, I am surprised.
TIP1: If you use CMP EnityBean instead of BMP ENTITYBEAN, there is a lot of performance in many cases. Specifically, high, see specific EJB IMPLEMENT. Of course, the more professional import, the higher the degree of optimization.
TIP2: The synchronous behavior here (Ejbload / EJBStore) is related to the transaction. The strategy for specific EJB IMPLEMENT implementation is also different. Synchronous problems, very difficult. It is not only difficult to handle, but also the impact on service performance is very large.
So, I think, EJB Specexpert Group should consider and redesign the EJB working model.
3, enhance EntityBean function
EJBQL is too weak, and the table - object mapping supports it is too weak, etc. It is necessary to improve the demand.
4, EntityBean Engine
Under a particular EJB model, each EJB IMPLEMENT vendor can fully display technical strength is to develop high-performance CMP EntityBean Engine. JFOX does not implement Entity Bean, while JBoss's Jaws is quite simple before 3.x.
5, very good positioning entity bean.
A long time ago, the view when writing this article
Designed unbiased Persistence Engine. Entity Bean does not need to be close to hibernate, which is essentially not one thing, Hibernate is in my opinion, is a special (lightweight, dynamic execution) translation middleware, its upper layer is an object view, the lower layer is The SQL view for the data source, and the Entity Bean is positioned to be static server-side service components. It only needs a persistence engine that can support the fixed function. The major work should be placed: re-designing EntityBean Work Model from performance, and enhances the function of CMP EntityBean.
Reflections on "EJB, Hibernate, Spring: Analysis, Criticism, and Outlook"
We don't have to say how much the ejb2.x itself is, after all, it is the product of the previous J2EE era, can only say that EJB2.x can no longer reflect the actual needs of most J2EE applications. out-of-date. So where is EJB3.0 plan to take us? EJB3.0 SPEC has made a lot of modifications in addition to simplified development, convenient testing, convenient deployment, etc., more importantly, EJB3.0 has a comprehensive intensive surgery for SessionBean, especially the ENTITYBEAN model. This modification is revolutionary.
In my "If I want to improve the EJB2.x model", I talk about, if I make me modify the EJB2.x's EntityBean model, then first need to set up a new model. Take EntityBean.
First Road: Continue EntityBean Design First Try: Remote Domain Model (including the ANAEmicDomainObject represented by the Domain Model and CMP EntityBean represented by BMP EntityBean, and retains the local interface, trying to change the design of persistence model, improve performance (even CMP EntityBean) The performance is also difficult to accept, this situation, I personally think that it is mainly because the EntityBean model is not good, in my other "If I want to improve the EJB2.x model", I have an in-depth analysis), Enhancements (EJBQL is too weak), let those connected to SessionBean, EntityBean need to deploy applications on different Server to EJB2.x's EntityBean.
However, obviously, the EJB Server provider is impossible to be willing to be willing to be willing, because the application is too small. The facts have proven that if the transitybean's Remote is not required, the RemoteEntityBean performance is not feasible, it can only work in the back end of the sessionBean, however, even if the EntityBean works in the back end of the sessionBean, there is too much limitations. The granularity is either too thin, performance, function is too weak, and so on, the development data is very flat, then if the Remote EntityBean is not a must, I don't completely give up EntityBean, use other in the back end of the sessionBean O / R Mapping Tool to develop data applications, such as Hibernate. This is, EntityBean can take the second road. Of course, in a sense, it is also the way it must go.
The second road: completely abandon ENTITYBEAN, using O / R mapping engine such as Hibernate as a backend data persistence tool for session beans, Message-Driven Beans. From EJB3.0, EJB3.0 does completely abandon the traditional EntityBean model. Personal: You can say this, EntityBean has no longer existed, and Expert Group gives you a very sharp's persistence engine in SessionBean. You hold the engine, what you want to do (above, EntityBean, PersitencyEngine is clear to the client, which is determined by the essential effect of these two engines. Some people say that Dynamic Query can be used in EntityBean Application, which can only declare EJBQL in the configuration file, these are the nature of both Persistence Engine. Determined). The EntityBean of the mandatory model does not exist! In addition, the EntityBean Remote feature is not mentioned in EJB3.0, perhaps only as an optional feature (I haven't thought that in EJB3.0, how to support Remote Po, this problem is very strange). It seems that Expert Group has completely denies the design of EntityBean, or EntityBean does not meet the actual needs, REMOTE EntityBean, Remote Domain Object is unrealistic in most cases. Words: Hibernate and JDO relationship, very subtle. EJB3.0 and JDO merger, Gavin enters EJB3.0 ExpertGroup is confusing. The persistence model of EJB3.0 uses JDO, which should be taken. However, at present, the Persitance Engine part of EJB3.0 seems to be around Hibernate, then where should JDO's location?
5. Improve the scalability of EJB added value function, easy to use,
Thereby increasing the competitiveness of EJB. EJB Set SECURITY, TIMER Service, RMI / IIOP and CORBA Interaction, etc.
Sex, it should be very concerned, there should be a wide range of applications. But why, these added value functions, we often don't use it, here, I will focus on SECURITY. 1, EJB's security development is very complicated.
2, and EJB itself integrate too close, no scalability
3, the safety model is too fixed.
6. Integrate a wide range of EJB Patterns into EJB Server
In this way, it can greatly simplify EJB development and improve project quality.
For example, add a Layer (Serializable) to buffer Home Handle when the client is restarted, and notify the client cache update when the server is restarted. Of course, if the Home Handle ID is not generated by the algorithm, the client does not need to update. Speaking of this, I feel, a small small in JFOX is: In ClientContainerInvoker, using Map, cache a variety of ContainerInvokeRService through the Naming Service query.
Seven, Dynamic Proxy, Reflect, these two technologies, seriously affect performance,
Design alternative technology. It seems that many EJB Server does not use these two technologies, such as APUSIC, but I don't know how they do it.
Revision Record: First: 6/10/2004 Second This: 10/28/2004
