Is there one entity bean instance per primary key ( I'm not concerned about server clusters situations )
I have seen lots of instances of an entity beans being created in response to a repeated ejbFind() with the same primary key.
I simply a put this.toString() in the ejbPostCreate to monitor the instances being constructed. ( I'm using WebLogic )
From the postings I've read there seems to be some confusion about this. Some say it's strictly a one to one relationship, others, like myself, have see a many to one relationship.
From the logical point of view (logical design) you can assume, that it's the one-to-one relationship. Application server is hiding multiple instances with the same PK from you (except direct call like this.toString() or this.hashCode()).
From physical architecture point of view it should be one-to-many relationship. Mechanisms inside WebLogic (or WebSphere etc.) must handle many concurrent users contacting the same bean, control caching etc. Of course, this should be transparent to you. Even if there is more than one instance with the same PK, the Entinty Bean should act correctly. This is EJB container reponsibility.
Methinks that WLS creates one entity bean instance per PK and serializes accesses to it - this allows for caching.
Another possibility is to create instance for each new transaction, which will be probably supported in the next WLS release and strategy can be specified in the deployment descriptor.
When multiple clients share an entity EJB :
They receive their own instance ; but they share the underlying data..and they dont need to handle synchronization as its being taken care by the container..
Hope this helps
Is this universally true for all app servers, i.e., a feature defined by the EJB 1.1 spec, or particular to an app server like WebLogic?
I dont think its for specific app server ; cause all the books ( Ed Roman and Oreilly (EJB) book) point to the same concept.
Ed Roman says :
To boost performance , we could allow containers to instantiate multiple instances of the same entity bean class.This would allow for many clients to concurrently interact with separate instances , each representing the same underlying data.Indeed this is exactly what EJB allows containers to do.Thus , client requests do not need necessarily need to run independently - they can now run simultaneously in several different bean instances.
So I think its upto the container developer to decide which strategy they choose ;but the EJB specification allows for multiple instances .
Do you know how the additional instances are initialized when they are created? Are they initialized from the db (activate and load called) or are they copied from an existing instance? I have been trying to find out the answer to this question for awhile now, but no one seems to know. Thanks for any help.
Even I would like to know what happens behind the scenes..but I guess since thats container specific..details wont come out from the vendor.
That sucks. I cannot be the only one who something like this would matter to. What if you are holding information in the entity bean that should be different from entity bean to entity bean with the same primary key. Take the Primary Key generator pattern in the Patterns section of this site. That Primary Key generator Entity Bean grabs the prefix of the id from a db (High value) and caches it in the bean. It also holds the suffix of the id as an internally generated number (Low value). It builds the id by appending the suffix to the prefix. What happens if you are using the caching features of your app server that also supports multiple entity beans with the same primary key? The potential problem that I see is that if the app server creates new entity beans and it creates them by copying an existing enity bean you could get duplicate primary keys. Preferably the app server would still call the activate and load methods on the new entity bean, that way you could invalidate the high and low ids. Maybe the solution is not to use entity beans for this pattern. Please let me know if I am wrong in my logic. Thanks.
Whether one or more entity beans with the same primary key may exist at any one time is up to the application server provider. Weblogic will only create a single instance of an entity bean with a given primary key on a single server instance but in a clustered configuration there may be one or more instances present at any one time. As far as updating the state of the bean goes, the container uses a refresh from the database (ejbLoad) before allocating an entity bean to a method invokation. Specifically for Weblogic, there is a document you can get from their site that describes the EJB container for both clustered and non-clustered configuration in a lot of detail.
Hope this helps,