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

488/158 ICE questions & 488/155 resources page

 
Bruce Yu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An ICE 488/158 Question:
Given the design goal of having an application be able to be configured as robust as possible, which techniques should the developer AVOID in their 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 either java:comp/ JNDI reference or EJB environment values.
(2 correct answers)
What is the correct answers and why?

BTW, I created a resource page on my home page.
Thanks,

Bruce
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bruce,
I am not sure on this one, too. I don't manage to get more than 85%.
Also I find it dificult to map the questions to the answer topics.
Here's what I think:
Its a two-part question. Its a or b and c or d.
First part:
It should be a) because (not sure), persistence sessions is a mechanism where the session object data is stored in a database (don't remember where I read that. Repeat: not sure). These data are there on server shutdown - restart. The stateful session beans are lost. So its a).
Second part:
Its d) because you can change the jndi location of the beans and map the code-location to the real location in deployment descriptor. Not sure neither.
Thank you very much for the ressource page.
Axel
correct me if I am wrong.
I would like to say well its that, read this page on that ressource, but currently I can't.
[ May 23, 2002: Message edited by: Axel Janssen ]
 
Bruce Yu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Axel, Thank you very much for your apply.
Your analysis gave me some hint. I did the ICE again and got the correct answers: b & c.
for a or b, at first I thought a was OK since WAS could make stateful session bean persistant OR programmer could code themself for the stateful session bean to persist its state.
for c or d, make references to node specific resources was not good since if it couldn't provide failover in case server down or for load balance issue. But this test is for Single Version WAS, it should be thought that way. I am not sure if I am on the right track.
Another qurestion on ejb transaction:
26) While testing a BMP Entity Bean, a developer discovers that a transaction rollback does not cause a rollback of the changes made to the bean as it should. Which of the following should the developer suspect?
a) The ejbPassivate() method has a bug.

b) The ejbStore() method has a bug.

c) The ejbCreate() method has a bug.

d) The datastore does not support JTA.

e) The transaction does not implement javax.transaction.UserTransaction.
Multiple Select - Please select all of the correct answers (this question has 2 correct choices).

What is correct answer and why?
Thanks a lot!

Bruce
 
Bill william
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The answer shd be b,c
Originally posted by Bruce Yu:
a) Use persistent HttpSessions to manage application state data.

yes, we use persistent HttpSessions for failover purpose.

b) Use Stateful Session EJBs to manage application state data.

no, Stateful Session EJBs are used to manage session level data


c) Make references to node specific resources

no, again, making references to node specific resources is not a good practice, as mentioned by Bruce above.

d) Make all resource references via either java:comp/ JNDI reference or EJB environment values.

It is a good practice to manage resources.
[ May 25, 2002: Message edited by: bill william1 ]
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am surprised too by Bruce's b c theory, but as he checked in the test...
Make all resource references via either java:comp/ JNDI reference or EJB environment values, but how it relates to robustness (the question).
For the new question: not clear neither. Am thinking about it. So far no solution.
 
Mohit Deshpande
Ranch Hand
Posts: 42
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all,
I am observing this discussion from a long time.
Thought let me participate.
This is my interpritation and inference.
a) The ejbPassivate() method has a bug.
This option is out ,because it has nothing to do with Rollback ie Transations
b) The ejbStore() method has a bug.
This option is out , it is only called if transation is successful. our case is roll back.

c) The ejbCreate() method has a bug.

d) The datastore does not support JTA.
e) The transaction does not implement javax.transaction.UserTransaction.
There's no specific mention of User transation or
Container managed transation in question so it leave only option c & d.
Please correct me if I am wrong.
Thanks,
Mohit
Multiple Select - Please select all of the correct answers (this question has 2 correct choices).
 
Bruce Yu
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that d is correct. But I think b could also be a correct answer.
Anyway, I feel these transcation questions in ICE488 are difficult.
I have other 3 transcation questions, could anyone show the correct answers and reasoning.
25)
While executing a method on a Session bean configured with TX_BEAN_MANAGED, an IllegalStateException is thrown when trying to commit a transaction that spans multiple business method calls on the Session bean. A cause of this problem may be that:

a) The Session bean is declared as stateless.

b) At some point an exception has occurred and the transaction has been rolled back.

c) An Entity bean accessed in the scope of the transaction marked the transaction for rollback.

d) The Session bean method that starts the transaction was never called.

Single select
28)
While testing a Session bean configured with "Bean Managed", a developer discovers that a TransactionRolledBackException is being thrown by a call to a method on an Entity Bean. The Session bean, prior to calling the method, explicitly started the transaction. Possible causes for the exception are that the:

a) entity bean method is throwing a checked exception.

b) entity bean method is throwing an un-checked exception.

c) entity bean is configured with a transaction attribute of "Not Supported".

d) entity bean method is throwing an exception and the entity bean is configured with a transaction attribute of "Requires New"


Multiple Select - Please select all of the correct answers (this question has 2 correct choices).

29)
The following sequence of method calls occurred on a CMP Entity bean instance when a Session bean invoked its businessMethod1() and businessMethod2() methods from the same Session bean method in IBM WebSphere Application Server, Advanced Single Server Edition for Multiplatforms:

entityBean.ejbActivate() entityBean.ejbLoad() entityBean.businessMethod1()
entityBean.businessMethod2() entityBean.ejbStore() entityBean.ejbPassivate()

Assuming that the session bean is configured with TX_REQUIRED, what MUST be TRUE about the scenario that generated these method calls?

a) The business methods are NOT configured with TX_REQUIRES_NEW.

b) Any persistent state changes that occur as a result of businessMethod1() are in the same transaction scope as changes made by businessMethod2().

c) Any persistent state changes that occur as a result of businessMethod1() are in a different transaction scope than changes made by businessMethod2().

d) ejbStore() will write the resultant state of the Entity bean to the persistent store.

Multiple Select - Please select all of the correct answers (this question has 2 correct choices).

Thanks,
Bruce
 
Axel Janssen
Ranch Hand
Posts: 2166
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if anybody has read this before I changed answer for question 28
The following is my summing-up of Monson-Haenffel 421ff. I am not very familiar with the specification yet, but it seems readable.
Summing up made my perspective somewhat clearer. But I might be wrong.
A very important point is that the EJB-Container behaves very differently towards system exceptions or application exceptions during transactions.
What are system exceptions, what are application exceptions?
An system exception is any exception that does extend java.lang.RuntimeException or java.rmi.RemotExceptions. EJBException extends Runtime exception.
All the rest are application-exception. Some of the EJB life-cycle and the finders throw application exception (e.g. CreateException, DuplicateKeyException, FinderException, etc.).
(as we all know from basic java:
A method is not required to declare in its throws clause any subclasses of RuntimeException that might be thrown during the execution of the method but not caught.
)

If you define your own exceptions in an ejb method you should use application exceptions.
Some of the standard exceptions of ejb-lifecycle and finder exceptions are application-exceptions too (for example: CreateException, DuplicatedKeyException, FinderException, ObjectNotFoundException, etc..

In what do they behave differently?
A system exception is handled automatically by the container:
- the transaction is rolled back
- the exception is locked)
- the transaction is rolledBack
- the ejb instance is discarded.
The last one invalidates the clients reference to the EJB. Subsequent method calls on the home or remote interface result in a NoSuchObjectException (subclass of RemoteException)
A application exception does n.o.t result in a transaction rollback. Although one ressource won't commit (an application exception is thrown) the transaction manager will commit the transaction (heuristic decision). This may lead to inconsistent data.

Whats the reason for that different behaviour?
The idea is that the client-(code) can recover through correcting the application exception. If this is not possible, you can use the method setRollbackOnly() of the javax.transaction.UserTransaction interface. A dereferenced, garbage collected ejb instance sometimes is to strong as an effect.

And if I can't correct the error?
That's what setRollbackOnly() in the UserTransaction interface is for: You can veto transactions. Transactions marked with setRollbackOnly() can't be commited.
25)

a)
spans multiple method calls. must be stateful.
NO

b)
if it is a system-exception the ejb-object would be dereferenced. If application exception commit would be possible (without call to setRollbackOnly()
NO

c)
this won't result in an illegal state exception, but a TransactionRolledBackException
NO
d)
The Session bean method that starts the transaction was never called.
YES

28)
see explanation above.
a)
no

b)
yes
c)
(no)
d)
(yes)



29)

a)
YES. If so, one would have to commit the transaction and start a new one before call on businessmethod2.
b)
YES. Same as a)

c)
YES. Same as a)

d)
NO. This will be written when transaction is commited.

Don't believe blindly what I say.
Correct me if I am wrong.
More questions. More answers.

Axel
[ May 27, 2002: Message edited by: Axel Janssen ]
[ May 27, 2002: Message edited by: Axel Janssen ]
 
xiaolin yu
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Replication
WebSphere Application Server provides a service that transfers data or events among WebSphere Application Server servers. The service is called WebSphere Internal Replication, or replication for short.
The replication service transfers both J2EE application data and any internal data used to maintain the application data among WebSphere run-time processes in a cluster of application servers.
Currently, the Web container in WebSphere Application Server leverages replication.
The replication service can replicate HttpSession data among processes and retrieve the HttpSession if the process that currently maintains the HttpSession fails. Using replication for HttpSession failover provides a potentially lower cost and more easily administrable alternative to storing HttpSession in a relational database. Further, the service can distribute across a WebSphere cluster information on invalid data and actual cached data maintained by a Web container's dynamic caching.
URL link: http://publib7b.boulder.ibm.com/wasinfo1/en/info/ae/ae/crun_repl.html
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic