Web hosting service - 128 Chapter 6 idea, it is not very
128 Chapter 6 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 interact concurrently with separate instances, each representing the same underlying entity data. Indeed, this is exactly what EJB allows containers to do. Thus, client requests do not necessarily need to be processed sequentially, but rather 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 through caching (see Chapter 19), we re dealing with multiple in-memory 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 12. Transactions enable each client request to be isolated from every other request. They enable clients to believe they are dealing with a single in-memory bean instance, when in fact many instances are behind the scenes. Transactions give clients the illusion that they have exclusive access to data when in fact many clients are touching the same data. Entity Bean Instances Can Be Pooled Let s say you ve decided to author your own EJB container/server. Your product is responsible for instantiating entity beans as necessary, with each bean representing data in an underlying storage. As clients connect and disconnect, you could create and destroy beans as necessary to service those clients.
Please check java servlet web hosting services, here you will find professional-grade java servlet web hosting with the best prices.