An interesting note to this is that when upgrading from 2.4 to 3.0, I had to actually make a foreign key optional from mandatory to get rid of a CMR error.
In this case, however, the setting of the forein key to a valid not-null value is part of the same transaction as the create, and cannot be modified later. Thus, via a transaction, the application still effectively enforced a mandatory foreign key. This was accomplished using a session bean.
I suspect that since even within a transaction the setting of the foreign key can become a separate SQL statement, CMR needs this flexibility. You just need to design your application to include setting the foreign key in the same transaction as the create via a session bean or some other method, and then not permit a null to be set.
I found the rationale from the spec:
The entity Bean Provider must not attempt to modify the values of cmr-fields in an ejbCreate<METHOD(...) method;
this should be done in the ejbPostCreate<METHOD(...) method instead.
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(...) has been called, or to the end of the transaction), ***depending on the caching strategy that it uses***.
We concluded for mandatory assoications:
- That we want to stick to NOT NULL FKs (otherwise you are seriously violating your referential database constraints - consider for example when another program access the database).
- That deferred transactions would resolve the problem (I think your session bean solution also utilizes on this), but that we do not want to use this, since some DBMSs do support deferred transactions (in different fashions), and some do not.
- That we could utilize on a container setting (like weblogic is offering: 'do not store in between ejbCreate and ejbPostCreate'). Reading the following thread suggests me JBoss also intends to support this in a subsequent version
- That we also could stick to BMR using lcoal interfaces.
I need to check if the EJB2.1 spec addresses this issue.
The EJB2.1 spec proposed final draft does not make a change on this subject.