• 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
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

ICE 287 Qs

 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have some questions that I wonder, could you help me a favour?


5. Given the design goal of having an application be as robust as possible, which techniques should the developer AVOID in the design?
A. Use persistent HttpSessions to manage application state data.
B. Use stateful session EJBs to manage application state data.
C. Make references to node-specific resources.
D. Make all resource references via java:comp/env JNDI references.
ANS:- B,C
Select 2 answers.


Should this be A, C?
The question is asking which options should be avoided, and thus, I think we should not use presistent HttpSession to store data.

9. When setting up the JMS server, in a test environment which is already running message-driven beans (MDB), which of the following properties MUST be configured to correctly communicate messages to a new MDB?
A. Queue JNDI name
B. Initial state to: Started
C. Queue name
D. Connection factory JNDI name
E. Listener port name
ANS :- b,c
Select 2 answers.


I am a bit wonder, since the server is already configured to support MDB, we now just add a new one. Thus, there should be no effort for the server part.
In Howard's book pages 210 and 211, when we create a new MDB, we need to provide the listener port name, and thus, I think E is one of the answers.
How about another one? I guess should be B, as A and D are related to server config, and C is not required in the DD, while Destination Type is required.
Any comments are welcome. Thanks.
Nick
[ March 25, 2004: Message edited by: Nicholas Cheung ]
 
Ranch Hand
Posts: 166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A and C are correct for the first question, don't know about the second.
 
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nick and Serge,
I agree with both of you about Q1 (A & C).
Ray
 
Ramon Gill
Ranch Hand
Posts: 344
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nick and Serge,
I agree with both of you about Q1 (A & C).
Ray
 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answers for Q1 should be B and C.
Here is the reasons:
1. Stateful Session EJBs have a limited lifespan and are NOT intended to survive server crashes. (Keep in mind the question requires an app be as robust as possible.)
2. Systems that have JSP/servlet front-ends should use HttpSession objects to store session-oriented state on behalf of a client. For systems that do not have a servlet/JSP front-end, Stateful Session EJBs should be used to track session-oriented state similar to the way a web-based system would use an HttpSession object. This was the primary intent of Stateful Session EJBs when they were created.
3. Persistent HttpSessions can cover-up the session failover situations.
Hope this helps.
BL
[ March 26, 2004: Message edited by: Brycex Lin ]
 
author
Posts: 361
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
B and C are the correct answers for both.
 
Would you turn that thing down? I'm controlling a mind here! Look ... look at the tiny ad ...
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!