Andrew Turnbull

Hi there.
No!
As far as I can tell from my SCEA notes, the sole purpose of calling a remove method (be it from on a home interace or a remote or local interface) is to remove some specific entity data from the underlying persistent store (database).
Once that data has been removed, then you can no longer have an entity bean that represents that data.
Passivating an entity bean is a technique used by the container to manage pooling and load balancing. A container passivates a bean instance in order to free up resources, but still save the state of that bean to be activated and used at some point in the future.
If you are destroying the data that a bean represents, then it makes no sense to first store away that bean's state for future use!
The CMP and BMP entity bean sequence diagrams (Mastering EJB 2, Appendix E) show all the actions and parties involved in both bean passivation and removal - they should help explain this.
Cheers, Andy
[ February 09, 2003: Message edited by: Andrew Turnbull ]

Hi there.
False!
ejbFindByPrimaryKey() is just like any other finder method that returns a single record: If a representation of your primary key can be found in the database, then the container will create the remote and local objects for the client to invoke business methods on, and associate an entity bean instance with those objects at that point.
The confusion possibly arises from the lifecycle statechart diagrams describing entity beans (see Mastering EJB2 Appendix E). These show the bean remianing in the pooled state after an ejbFind method has been called (after a client called a finder method on the home interface).
This implies that the bean remains in the pooled state after you ejbFind method has executed - which is a little befuddling...
What I'm guessing happens is that the container returns a remote and local interface to a bean which is either already in the ready state, or is activated by the container when you call a finder method. The home object on which you called your finder method might not be one of those beans referenced, and hence might well stay in the pooled state.
I hope that helps, and doesn't confuse the matter. I myself am a little confused over the entity bean lifecycle diagram, as I don't see why these diagrams imply a state relationship between an ejbHome object and a bean instance - these seem to be two separate container managed entities to me.
Can anyone else shed any light on this?
Cheers, Andy
[ February 09, 2003: Message edited by: Andrew Turnbull ]

I can also recommend Mark Cade's book, primarily for it's discussion on the 'softer issues' i.e. Security, Legacy Integration and J2EE applicability.
I don't think the Cade book covers EJB's or the container model in sufficient detail - see Ed Roman's (free) Mastering EJB Edition 2 for these topics.
I would have bought Paul Allen's book if it were available - Amazon states that: "This item will be released on March 19, 2003".
Has anyone read an advance copy yet?
Cheers, Andy

Hi there.
Point-to-point messaging is where one or more senders need to send messages to a single receiver.
There are two basic implementations of ptp messaging, the first is where the sender sends a message directly to a receiver, while the second is where a sender sends a message to a specific queue (which may provide delivery-guarantees).
See the diagram on this page: http://my.execpc.com/~gopalan/jms/jms.html for a clear explanation.
In summary, yes ptp is the same as a message queue system, and yes you can have many senders.
Cheers, Andy