The entity object created by the ejbCreate<METHOD> method must have a unique primary key. This means that the primary key must be different from the primary keys of all the existing entity objects within the same home. However, it is legal to reuse the primary key of a previously removed entity object. The container may, but is not required to, throw the DuplicateKeyException on the Bean Provider�s attempt to create an entity object with a duplicate primary key  .
What would happen if the primary key was the same as a database entity but not an existing entity object? Wouldn't this also be problematic? HAPPY NEW YEAR!!!
The Container makes a distinction between the *entity bean* primary key and the underlying primary key in the database. The reason is that there is really *no* requirement in the spec that the actual THING the entity bean maps to (the *real* entity) is something that even HAS a primary key. So as far as the EJB spec is concerned, the only thing that MUST have a unique primary key is the entity bean itself. That bean might map to something in a database, or even something NOT in a database, and that thing may not even have a primary key of its own (it is up to YOU to figure out how to uniquely represent it in a bean and give the bean its own primary key). So, DuplicateKeyException is about trying to create an entity bean with a primary key that the Container sees is already in use, assuming the Container can *tell*. Now, your database may be set up in such a way that when you try to do the insert with an existing key, the database itself has a problem, but that is a separate issue. Remember, in ejbCreate(), the Container has not yet done the insert (for CMP) -- it does the insert *after* ejbCreate(), by looking at what you've set your designated PK field to, and uses that value as the primary key to do the insert. But if the Container can already tell that your PK field value matches an entity that it knows about but which has not been removed, then you can get the DuplicateKeyException. Also remember that you might have a primary key for your bean that is simply a composite/compound key made up of multiple field values from the *real* entity in the DB... and remember too that the entity bean might be mapped to something that doesn't look anything like a single row in a relational database, even though *most* of the time that is what we're talking about. But the spec doesn't care WHAT you store your real entities in, as long as it is something that can be considered "a persistent store". cheers, Kathy
Hi Kathy: I'm still a bit cloudy on this topic. My understanding of what a primary key is comes from the area of databases(naturally). A primary key is used to ensure that all records of a database table have a unique identity. If an attempt to insert a record in the table having a primary key equal to a record currently in the table the database will complain and will not allow it. I'm not clear on the purpose of the entity bean primary key. At first, I assumed that it did map directly to the primary key of a database table. You made it clear in your last post that this is not the case. Why not? I understand that the container ensures that an entity bean can not be created if is aware of another bean with the same primary key. What purpose does this serve? This fact doesn't seem ensure uniqueness like in a database. What if an there is an entity with the same primary key that the container does not know about? What is to prevent the creation of the entity in this case? Wouldn't this be a problem? How does the container become "aware" of an entity? Is this as the result of a find or create? Is the container "aware" of all the entities of the persistant store?
Please help remove these question marks from my head and put a smile on my face. Like this Thanks
If there is another db record with the same primary key as the one you are trying to create then the primary key violation will occur and the client will get a RemoteException/EJBException while invoking create method of the home object. This is not the problem of the container but yours as long as you manage the primary keys. Of course, the container does not need to know about all entities in the persistence store. The spec does not require that and it hardly makes sence. SCWCD should know such things
Hi Siarhei: I appreciate your reply but my questions still are unanswered. I cleary understand the WHAT. It's the WHY that confuses me. Please re-read my last post and you will see that is the case. Thanks,
Keith Rosenfield<br />SCJP<br />SCWCD<br />SCBCD
Uh oh, we're definitely being carded. Here, show him this tiny ad: