5 simple J2EE test questions

[Stephen Lim]

Dear folks,
I was doing an eval test on J2EE, and I find that some of these questions to be a challenge. The results was OK, but I do not know which question I've got wrong. Can someone pls reveal the answers to them...
Q1. Which statement is true about statefull session beans, but is NOT true about stateless session beans

A. State can be cached but is not representative of the client state

B. State can be cached but is representative of client state

C. State is persistent

D. State is cached first, then persisted.

Q2. Which statement on passivation is true

A. Containers must set the transient values to null or zero

B. Containers must use java technology serialisation to passivate a bean instance

C. Container calls ejbPassivate to save the entity bean instance's state to the database

D. Container can use any serialisation technique to passivate a bean instance as long as it follows Java technology serialisation rules.

Q3. Which transaction attribute should be set in the deployment descriptor for a method to guarantee that the method is NOT invoked with a transaction

A. RequiresNew

B. Supported

C. Never

D. Mandatory

Q4. What is the benefit of using DAO's with BMP based entity beans

A. Less code than a CMP entity bean

B. Faster data access tha CMP

C. Reduced coupling with entity bean

D. Easier to code than CMP entity bean

Q5. Which pattern is used by the Home interface of an EJB

A. Proxy

B. Decorator

C. Mediator

D. Factory

[stara szkapa]

B
A
C
C
D
[ July 31, 2003: Message edited by: stara szkapa ]

[Stephen Lim]

Heh, thanks.
By the way, where do you think I can access these sort of questions. Yeah, this level & type of questons? Do you reckon this is taken from some SUn certified tests?

[Jes Sie]

Wait a minute, I think Q2 is D. What do you guys think?
I do agree A cannot be ruled out as well

[Pradeep bhatt]

Yes, D is right but A certainly not right. The container is not required to set the transient values to null or zero.

Originally posted by Simon See:
Wait a minute, I think Q2 is D. What do you guys think?
I do agree A cannot be ruled out as well

[Pradeep bhatt]

From the spec
The one exception is that containers are not required to reset the value of transient fields during activation. Declaring the session bean�s fields as transient is, in general, discouraged.
Hope this answers the question.

[David L Gilbert]

In Q2, I go with D. Transient values should not be serialized at all - not even to null or zero - there should be no reference to them as if they never existed.

[Pradeep bhatt]

ejbActivate gives the bean provider the chance to reinitialize the transient fields.
But I have a question - Why is it not possible for the container to initialize the transient fields?

[Lasse Koskela]

But I have a question - Why is it not possible for the container to initialize the transient fields?

Because the bean developer told him not to by declaring those fields as transient? The transient keyword doesn't prevent reinitialization (serialization/deserialization) technically but it does prevent it logically. It's a bit like the "DON'T WIPE THIS!" text on a whiteboard...

[Pradeep bhatt]

The java serialization does reinitialize the trasient fields as well. I think the reason is beacause the container can use mechanisms other than the Java serialization.

Originally posted by Lasse Koskela:

Because the bean developer told him not to by declaring those fields as transient? The transient keyword doesn't prevent reinitialization (serialization/deserialization) technically but it does prevent it logically. It's a bit like the "DON'T WIPE THIS!" text on a whiteboard...

[Lasse Koskela]

The java serialization does reinitialize the trasient fields as well.

Huh? The javadoc for java.io.Serializable says the following:
The readObject method is responsible for reading from the stream and restoring the classes fields. It may call in.defaultReadObject to invoke the default mechanism for restoring the object's non-static and non-transient fields.
Also, Sun's Java Tutorial says the following:
The transient marker is not fully specified by The Java Language Specification but is used in object serialization which is covered in Object Serialization to mark member variables that should not be serialized.

I think the reason is beacause the container can use mechanisms other than the Java serialization.

Umm. Now you've lost me Pradeep. This is the reason for what? Well, anyway the container could read the state using reflection and store it -- including transient variables -- into a persistent storage for later.