Database integrity violation errors usually indicate a bug or a problem with the design. Nevertheless, the logic enforcing value and referential integrity is necessarily duplicated. Changing the integrity rules in the database will usually also entail changes to the code, and keeping the two synchronized can be a problem. While simple value and referential integrity constraints are fairly portable, databases differ in coverage and syntax for more complex mechanisms such as complex foreign keys, generated triggers, and especially procedural triggers. Procedural triggers in particular are portability concerns, because, when offered, they are often written in the database vendor's product-specific proprietary language.
Configuration is uncontrolled.
Since database constraint and trigger configuration is performed with the database vendor's tools, such constraints are maintained outside of the J2EE server framework. Since the data model constraints are specified not in the deployment descriptor, but in the persistence layer, such constraints are not part of a J2EE server deployment. They must therefore be managed separately, complicating deployment and maintenance, and providing another possible avenue for system flaws. Value and referential integrity constraints may also be implemented in the EJB tier. The constraints you need for your application may simply not be available in the databases you choose.