Hi Daniel, I have read through your recent posts about entity beans, cpu and java virtual machine capacities, performance etc as we have a tool call Bean-test that measures EJB performance so I was curious. I sense that you are learning about what a J2EE application server does, how that works with the Java Virtual Machine, and how Enterprise JavaBeans work, etc.
Basically the J2EE application server runs the EJB for you, takes care of managing all the calls for an EJB, and for container managed persistence (CMP) also takes care of all the connections from the EJB to the database where the actual persistent data is stored. The J2EE application server typically runs within a single Java Virtual Machine process, but it is really the application server program that handles all the requests to the EJBs. Each application server vendor will implement things differently but typically calls to an EJB are managed via queues of the requests, pooling of available EJB instances to handle those requests, and pooling of connections to the database. Concurrency then is a notion that multiple instances of an EJB (i.e. different entity bean instances of the same type) can be executing a method at the same time. I am not sure what your intended use is where you would like to eliminate concurrency, but my suggestion is that you look further into the deployment descriptor settings for entity beans for your application server to learn more about what you can specify to the application server how the concurrency should be handled in terms of limiting the number of concurrent instances and, to add another level of complexity, how database access is handled in the case of multiple EJB clients trying to access the same entity bean at the same time. Your application server vendor should also be able to tell you the hardware and operating system requirements for running your EJBs at the particular load you are considering. The Mastering EJB book described on TheServerSide.com is also a good reference for learning more about how things work (http://www.theserverside.com/books/masteringEJB/index.jsp). Remember that even though the application server can do many good things for you in terms of providing good performance, you are still responsible for creating a well architected and implemented implementation that will perform well. For example your application architecture could have artificial bottlenecks in it that you could never overcome by changing application server settings or adding more memory or CPUs. There are prior posts about EJB access patterns as well as many books and articles available for you to read about good J2EE architecture design patterns. One place to start might be the J2EE Blueprints site at http://java.sun.com/blueprints/. I hope this helps, -Chris Thompson Bean-test Developer http://www.empirix.com -----Original Message----- From: daniel legziel [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 24, 2002 8:48 AM Subject: entity concurrency problematics Hi all, I have a question about concurrency with entity beans. Is concurrency a notion that depicts (using JMS) simultaneous messages to an entity object or to the entity's container? In other words is eliminating concurrency at the object level (by using a message driven beans hub) sufficient or will the messages jam at the container level? If so what can be used to avoid this? Thank's in advance Daniel _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
