How does the EJB container handle a situation where
a particular table has the ON DELETE CASCADE referential
integrity constraint. That is when a parent record (entity
bean) is removed on the container side, that record along
with all it children record are deleted on the DB side.
Should we treat ON DELETE CASCADE as DB is shared?
If not, how does the container finds out that a particular
table has the ON DELETE CASCADE set up?
Does the container ever extract table schemas using
JDBC MetaData API?
Here is a scenario:
CARD_1 is removed via ejbRemove().
PORT_A --\
PORT_B --- are removed on the database, but remain in ready
PORT_C --/ state on the container. someone else can invoke
a method on the PORT_A, and ejbLoad may not be
called (if DbIsShared is false).
On page 97 of EJB 1.1 spec, the diagram shows that a direct
delete should move the EJB object to "does not exist". But
I wonder how the container does that in the case of ON DELETE
CASCADE described above?
Rubens.
--
Rubens S. Gomes, Software Development Engineer
Fujitsu Network Communications, Inc.
ATM Network Management Systems Development Group
1000 St. Albans Drive, Raleigh, NC 27609 USA
Tel: 919.790.2539 Fax: 919.790.3330
===========================================================================
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".
