DuplicateKeyException question

[Keith Rosenfield]

The following quote is from one of the testing programs.

The bean code does not have to worry whether it is setting duplicate primary key values or not. The container checks whether the primary key set by the ejbCreate method is duplicate or not and if it is indeed duplicate, it throws a DuplicateKeyException to the client. No exception is thrown in the bean code.
For example, in the following ejbCreate method, no exception is thrown in the bean code even if the primarykeyid is already used. However, the client calling the create method will get a DuplicateKeyException.
public java.lang.String ejbCreate(String primarykeyid, String name, String value) throws CreateException
{
setPrimarykeyid(primarykeyid); // no exception is thrown here even if primarykeyid is duplicate.
setName(name);
setValue(value);
return null;
}

Does the container check for a duplicate key before calling ejbCreate()? If it does and the container determines that the key is a duplicate and it throws DuplicateKeyException does it bother to call ejbCreate().
Basically what I'd like to know the order of operation of the following.
- Check for duplicate key
- throw DuplicateKeyException
- Call ejbCreate()
Thanks.

[Marcos Maia]

from spec, topic 10.5.3
public PrimaryKeyClass ejbCreate<METHOD>(...);
public void ejbPostCreate<METHOD>(...);
The container invokes these two methods during the creation of an entity object as a result of a
client invoking a create<METHOD>(...) method on the entity bean�s home interface.
The container invokes the ejbCreate<METHOD>(...) method whose signature matches
the create<METHOD>(...) method invoked by the client.
Prior to invoking the ejbCreate<METHOD>(...) method provided by the Bean Provider,
the container must ensure that the values that will be initially returned by the instance�s get
methods for container-managed fields will be the Java language defaults (e.g. 0 for integer,
null for pointers), except for collection-valued cmr-fields, which must have the empty collection
(or set) as their value.
The container is responsible for calling the ejbCreate<METHOD>(...) method, for
obtaining the primary key fields of the newly created entity object persistent representation,
and for creating an entity EJBObject reference and/or EJBLocalObject reference for the newly
created entity object. The Container must establish the primary key before it invokes the ejb-
PostCreate<METHOD>(...) method.
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[15].
The container may create the representation of the entity in the database immediately, or it can
defer it to a later time (for example to the time after the matching ejbPostCreate<
METHOD>(...) has been called, or to the end of the transaction), depending on the
caching strategy that it uses.
The container then invokes the matching ejbPostCreate<METHOD>(...) method with
the same arguments on the instance to allow the instance to fully initialize itself. The instance
can discover the primary key by calling getPrimaryKey() on its entity context object.
Finally, the container returns the entity object�s remote interface (i.e., a reference to the entity
EJBObject) to the client if the client is a remote client or the entity object�s local interface (i.e.,
a reference to the entity EJBLocalObject) if the client is a local client.
The container must invoke ejbCreate<METHOD> and ejbPostCreate<METHOD> and
create the representation of the persistent instance in the database in the transaction context
determined by the transaction attribute of the matching create<METHOD>(...) method,
as described in subsection 17.6.2.
regards.

[Keith Rosenfield]

Thanks Marcos.
I guess the moral is "When in doubt, check the spec".

[Vishwa Kumba]

Marcos & Keith,
Could you explain a bit more clearly please...
I couldn't understand this...
So it is not mandatory for the Container to throw a DuplicateKeyException/CreateException if the row already exists in the database, assuming that there are no database constraints?