Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

conversational state of SFSB

 
Imran Vohra
Ranch Hand
Posts: 77
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I encounter one question of mock exam. I dont know the right answer.
can anyone please tell me which is the right answer and why?
Question is :-
public class TestBean implements javax.ejb.SessionBean
{
private transient int count;
private int userId;
private String userName;
private java.ejb.SessionContext context;
// rest of class follows
��
}

Referring to the sample code fragment above, which one of the following contains all the instance variables that are part of the conversational state of the Stateful session bean TestBean?

a)context
b)userId
username
context
c)count
userId
username
javax.ejb.SessionContext
d)count
e)userId
userName

Thanks
Imran
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer should be 'b'.If its correct and you affirm an explantion will follow
 
Imran Vohra
Ranch Hand
Posts: 77
Chrome Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am sorry but I dont know the right answer.
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My logic is..that passivation works like serilization(although the container may not use serialzation but the output result should be same besides one exception).

If i am talking about conversational state...i am talking about the fact that if a bean goes to passivated state and comes back..the state must be maintained ..

But if you look at the specs you will see that passivation works only for Non Transient instance variables ..there is a list to this..but transient variables are excluded straight way and hence the answer which i derived.

May be someone else can cross validate/reject this understanding
[ April 04, 2006: Message edited by: Rahul Mishra ]
 
Salil Surendran
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ya. b is the correct answer. Since String and int variables are serializable and will be saved and the spec mentions that the SessionContext object should be saved.
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think option C is the right one.

Sections 7.4 and 7.4.1 talks about the conversational state. The spec does say that "Declaring the session bean�s fields as transient is, in general, discouraged.", but I did not see anything in the spec that says that the transient field is not considered as part of the bean's conversational state.

Section 7.4 of the spec (Page 71)
The conversational state of a STATEFUL session object is defined as the session bean instance�s field values, plus the transitive closure of the objects from the instance�s fields reached by following Java object references.

In advanced cases, a session object�s conversational state may contain open resources, such as open sockets and open database cursors. A container cannot retain such open resources when a session bean instance is passivated. A developer of such a session bean must close and open the resources in the ejbPassivate and ejbActivate notifications.


From the first paragraph above, I can say that the definition of the bean's conversational state does not exclude transient variables.

From the second paragrah, I can assume that the fields which the container cannot retain across passivation/activation can also be part of the bean's conversational state.

Hence I would go with option C.
 
Balaji Anand
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
transient fields will not be restored to its value/initial value when the bean is activated again.
It is not part of the beans conversational state.
I think b is correct
[ April 04, 2006: Message edited by: Srividhya Anand ]
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ankit try looking up the list for passivation rules..either in HFEJB/specs..it should melt your doubts.
 
shri mon
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
transient variables cannot be a part of the conversational state of a bean because they will not be flattened out.Hence i think B is the correct answer


Thanks,
Shrimon
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for late reply on this ... Rahul and others, I checked the specs, and I gone through the sections 7.4.1, 7.7.5, 10.9, 12.4.3, 14.2.3 of specs, along with the other section that contains information on passivation, but I could not find any information which leads me to the conclusion that "the transient fields are not part of the conversational state".

Can you please give me reference to the spec section / reference to the HFEJB section or page number where I can get this info?
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
7.4.1 Instance passivation and conversational state
The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields
ready to be serialized by the Container. The objects that are assigned to the instance�s non-transient
fields after the ejbPassivate method completes must be one of the following:
� A serializable object[2].
� A null.
� An enterprise bean�s remote interface reference, even if the stub class is not serializable.
� An enterprise bean�s remote home interface reference, even if the stub class is not serializable.
� An entity bean�s local interface reference, even if it is not serializable.
� An entity bean�s local home interface reference, even if it is not serializable.
� A reference to the SessionContext object, even if it is not serializable.
� A reference to the environment naming context (that is, the java:comp/env JNDI context)

I have copied and boldened the part i referred to ...its 7.4.1 from spec
 
Ankit Doshi
Ranch Hand
Posts: 222
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let me be more specific here:

The Bean Provider is required to ensure that the ejbPassivate method leaves the instance fields ready to be serialized by the Container.

I think here we are talking about all the fields - transient and non-transient.

The objects that are assigned to the instance�s non-transient fields after the ejbPassivate method completes must be one of the ...

Here we are talking about non-transient fields only.

Where are we talking about the only *transient* fields?


From what I understand, you are trying to point out that since the state of the transient variables might not be retained after passivation/activation and hence they can not be part of conversational state. Is this correct? If not correct, then what is it? If it is correct, in that case aren't we just *assuming* the following?

because transient fields might not be retained across passivation ==> hence they are not part of conversational state
 
Rahul Mishra
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yep, now you get it right..

whatever wont survive activation/passivation can't form conversational state

Imagine you stored something into a transient variable...because of your pool size..the bean got passivated...then you invoked..a business method..the bean got activated...but your transient variable value got lost...in effect..i lost my conversational state...didn't i?

I ain't assuming i think..i am inffering...logically..
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic