Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question about an example in the book Mastering EJB 3.0 4th edition

 
Tom Kowalski
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,
I have got a problem with one of examples in the book Mastering EJB 3.0 4th edition. In chapter 4, the authors give an example of stateful Session Bean, the class of this bean has got those two functions (it has got more, but those are the two most important):



Later, authors configure the server, so in one time there could exists only 2 instance of the beans in the pool. Then, they write a client class and they are making three instance of this bean.
The output of the server is this (different functions in the session bean print different strings)



The author say that this is the proof that, one of the session beans passivated and then activated. I don`t see this proof. In my opinion, if this would happened, then one of the string in the output would be like this:



But this not happened. So why the authors says that we can see here an example of passivation and activation of the sessionbean.

Thanks, and sorry if this is stupid question ^^
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

The activate/passivate are life cycle callback methods but a bean can leave and die whiteout to use them.
In most of the cases the application server trigger this method when it tries to free some space or when it tries to move a bean from one application container to an other. In your case I don't think that the server runs out of resources .

Regards,
Mihai
 
Tom Kowalski
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mihai Radulescu wrote:Hi

The activate/passivate are life cycle callback methods but a bean can leave and die whiteout to use them.
In most of the cases the application server trigger this method when it tries to free some space or when it tries to move a bean from one application container to an other. In your case I don't think that the server runs out of resources .

Regards,
Mihai


Yes, but in the book, authors says that it is possible to change configuration of the server (GlassFish etc.) , so it could have only X (in this case 2) instance of the beans in time. And if the server will notice, that it have to use three instance of the beans, then it should treat it like the ‘out of resources’ and it should passivate one of the beans.
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

The book an describe a vendor specific behavior, even with this different version from the same application server can act different. You must read the Glassfish specification to see under which conditions the "pasivate" is triggered.
My point here is : construct/destroy are the only two call back methods certainly called. The pasivate/activate may be call (under some condition).

Regards,
Mihai
 
Karl Krasnowsky
Ranch Hand
Posts: 97
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mihai Radulescu wrote:Hi

The book an describe a vendor specific behavior, even with this different version from the same application server can act different. You must read the Glassfish specification to see under which conditions the "pasivate" is triggered.
My point here is : construct/destroy are the only two call back methods certainly called. The pasivate/activate may be call (under some condition).

Regards,
Mihai


Well, the book itself is kinda sloppy, IMO. If I'm understanding the point of the stateful bean example, the container should be limited to using only 2 instances of the bean, the creation of a third, therefore, should cause the PrePassivate callback to be called by the container. Even in the output of the example in the book there is no indication that this never happened, and goes on to say that
Then, as you can see from the passivation/activation messages in the log, the server is indeed passivating and activating beans ...
.

Okay, this is a free publication so some allowances can be made, but it would appear that the author(s) him/herself couldn't or wouldn't get the server to properly perform the requirement. Given the quality of other areas of the tutorial I'm not surprised (couldn't they have at least normalized the build scripts?).
But I still believe the material offers some good information.

~Karl
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic