That brings us to an interesting point on how EJB containers are implemented. For
eg, if an entity bean has a int primary key, and the EJB client tries to insert a
row with the same PK, the container throws DuplicateKeyException. The container
could be implemented in two ways :-
1) The container assumes that primary key constraint is available at the database
level.
try {
insert the row;
} catch (SQLException e) {
throw new DuplicateKeyException();
}
2) The container does not assume any db level constraints
select id from table where id = pk.id
if (rs.next()) {
throw new DuplicateKeyException();
}
insert the row;
I would wish that the container does #1. I think the container will not be able
to enforce all the constraints that a db would do naturally (simply because the
container vendors are not into database business :-). Also, we have containers
like WebLogic, where the bean developer can not specify the foreign key constaint
at an EJB level. That leaves the bean developer with only one choice - database
level constaints!
May be the vendors should pitch in and clarify on this point.
--
shiv
[EMAIL PROTECTED]
> >Hi,
> >
> >I had a discussion with a colleque of mine and we did not reach a agreement,
> >maybe some experts on this mailing list can help us out....
> >
> >The question is: Should you use database level constraints to enforce the
> >integrity of the database or is the integrity of the database the
> >responsibility of the EJB?
>
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".