Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

What does really happens during SFSB passivation?

 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, we know that during Stateful Session bean passivation, the container saves the bean in a sort of secondary storage to save resources between method invocations; this may be serialization.

I thought that the container may do something like the following, and I would like you to confirm what I think:

1) The container can have a pool of stateful session beans
2) When the SFSB is in the method ready state, its state reflects a conversational state with a unique client
3) When the container decides to passivate the bean, its state can be saved with something that acts as serialization, BUT THE BEAN THEN CAN BE PUT INTO THE POOL, READY TO SERVE ANOTHER CLIENT.
4) When the container receives a business method invocation for a SFSB that it passivated, it retrieves the serialized state, it TAKES OUT A BEAN OF THAT TYPE FROM THE POOL, it assigns the serialized state to the bean, and it invokes the business method on the bean.

5) THOUGH PHISYCALLY THE CLIENT HAS BEEN SERVED BY TWO DIFFERENT SFSBs, at his eyes IT HAS BEEN SERVED ONLY BY ONE, because it's the state that matters, not the actual physical object that contains it.

Am I correct? Is this something that is possible but is vendor specific?
 
Ranch Hand
Posts: 66
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

BUT THE BEAN THEN CAN BE PUT INTO THE POOL, READY TO SERVE ANOTHER CLIENT.



I dont think same session bean are allowed to serve 2 different clients, even when the are passivated.

in the spec 7.6.1, it says that the container CAN replace the following during ejbActivate(), but functionality identical
1. Object reference to JNDI and subcontents
2. An object reference to UserTransaction
3. Object reference to sessionContext

I cant find it in the specs for allowing a different bean, but on page 85 of Mastering E-Javabeans, it states: "Note that the bean that reeives the activated state may not be the original bean intance"
 
alzamabar
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Ryan Wong:



in the spec 7.6.1, it says that the container CAN replace the following during ejbActivate(), but functionality identical
1. Object reference to JNDI and subcontents
2. An object reference to UserTransaction
3. Object reference to sessionContext

I cant find it in the specs for allowing a different bean, but on page 85 of Mastering E-Javabeans, it states: "Note that the bean that reeives the activated state may not be the original bean intance"



This validates my theory that a bean instance can be reused, provided that the client keeps its original state.
 
Hey cool! They got a blimp! But I have a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic