hi, in the spec p.176, we can read, that the container must invoke ejbLoad before it invokes ejbRemove. Why do we need to syncronize the bean instance, assumed that the entity will be soon deleted and the instance will be sent back to the pool and will loose its identity? Is the only reason that ejbRemove() must be considered as any other business method defined in the bean, and as such, must synchronize the bean? Regards, Cyril.
SCJP 1.4, SCWCD, SCBCD, IBM XML, IBM Websphere 285, IBM Websphere 287
Originally posted by cyril vidal: Why do we need to syncronize the bean instance, assumed that the entity will be soon deleted and the instance will be sent back to the pool and will loose its identity?
I just dug around on this one, and it has to do with cascading deletes. If you think of deleting this one bean, alone in the universe, it seems "illogical" to synchronize only to throw it away. But if you understand that the bean has relationships that may be affected by this bean's removal, you think 'ah-ha!' it needs to be a "clean delete". So by making the bean "right with the world" before it goes to it's final resting place (the bit bucket), we can be sure that other beans will not be confused by the dissapearance. --Dale--
I just wanted to say that I thought Dale's explanation was both accurate and *emotional*. Now *I* can't stop thinking about those poor dying/dead beans, and the thought of other beans being potentially confused by the disappearance is equally evocative Anyway, I really agree with Dale-- it might appear wasteful to bring a bean to full bean life again only to kill it, but bean synchronization (i.e. bringing the bean out of the pool and populating with the underlying entity state) is needed to take care of any other possible relationships the bean might be participating in. cheers and thanks for the good imagery Dale! -Kathys
Have you no shame? Have you no decency? Have you no tiny ad?