Manish Sarlashkar

As the per the new rule, you must to submit the assignment first before scheduling the essay exam. I believe there is a difference between submitting/uploading and grading.

So, Oracle will not grade it until they have both the assignment and essay with them.

But to register for the essay, the assignment must be submitted first. And once you submit the assignment you can right away register for the essay and can take on the same day.

Also, please check the FAQs on the oracle site before submiting an assignment, if you have purchased the assignment from PRometric and trying to upload as in that case the exam code is 1Z0-848.

Define a new typed complexType , let's say 'full_name', which includes'first_name' and last_name and add the element 'full_name' to the Request type/element along with 'ssn' but now use 'xsd:choice' instead of 'xsd:sequence'. This will allow either 'full_name' or 'ssn'. But this will add one new element 'full_name' to encapsulate 'first_name' and 'last_name'.

The second option should work but looks like the "xsl" prefix is missing from the "value-of" element.

If it still does not work, please paste your complete xslt content here.

hi,
Let me try to answer the question by analyzing each option.
Please correct if I am wrong.
The answer is, 'b' and 'd'.
A. The ejbPassivate() method has a bug.
---> The ejbPassivate() (should) never have any Data access api even in case of BMP. Also, the ejbPassivate() executes without Tx context , so there is no way this method can corrupt a transaction.
*So this is not a correct answer.
B. The ejbStore() method has a bug.
---> The ejbStore() is executed at the end of the Transaction (with a Tx context of business method) and if the bean provider accindently calls the Tx api of the resource manager(database), this can corrupt the transaction. For example, in a BMP entity bean if a method starts a transaction and commits it, and within this scope, if you call commit() on java.sql.connection (obtained from DataSource), the data is commited in DB, but also the container throws a java.lang.IllegalStateException and rolls back the transaction.
So, your transaction is rolled back but the data is committed (means the state is not rolled back).
** So this is one of the right answers.
C. The ejbCreate() method has a bug.
--->The question is for, when data is changed and not when data is created.
**So this is not a correct answer.
D. The datastore does not support JTA.
--> This indicates that the Datasource does not support an external Tx manager and handles only local Tx. [Still trying to understand.... ].
** So this can be a right choice.
E. The transaction does not implement javax.transaction.UserTransaction
--> All containers, according to EJB 1.1 spec, must at least implement, javax.transaction.UserTransaction interface.
So choice 'E' can not be true.
** So this can not be a correct answer.
Thank you,
-Manish

hi Debalina,
Let me try to answer your question.
The IDLE_TIMEOUT defines the time out time from the 'Pooled' state to 'Does not exist' state for a connection in a pool. For this the state has to be 'Pooled' and not 'In use'. So this time out will not affect the connection which is in, 'In Use' state (by servlet).
Also, the MIN_POOL_SIZE value is 10, which is acceptable and the question does not have any further details on it.
So, let's evaluate eac option,
a) The servlet's connection will be unaffected by the idle timeout.
--> As metnioned earlier, the idle_timeout setting does not affect the connection in use. **Possible right choice.
b) The pool size will be increased by 10 when some other servlet needs a connection.
---> The min_pool_size is 10, but we do not know what is the current pool size, and also, even if the pool size is less than 10, the server never creates the pool with min size or increments the pool size with min size. But it keeps on creating one connection per request until the pool size reaches the min size and this is done only if, there is no connection in the pool that can satisfy the current connection request.
**So in any case this is a wrong choice.
c) After 30 seconds, WebSphere can return the connection to the connection pool.
---> Same explanation as given for choice 'a'. The idle_timeout does not affect the in use connection. This could have true only if, ORPHAN_TIMEOUT would have been set to 15 secs and the connection was not involved in a transaction.
** So this is not a right choice.
d) The servlet's service() method will throw a javax.sql.PooledConnectionException if the servlet attempts to use its connection.
--->There is no exception class by name, javax.sql.PooledConnectionException.
Also, the server will throw only StaleConnectionException in this case, only if the connection was orphaned or the connection was cleaned-up after a transaction (if DISABLE_AUTO_CONN_CLEANUP is false).
** So a wrong choice.
So option 'a' is the right answer.
For Webpshere Connection pooling refer to ,
(can search on google.com)
WebSphere Connection Pooling
by
Deb Erickson
Shawn Lauzon
Melissa Modjeski
Hope it helps.
-Manish

hi Mark,
I am trying to answer your question, please correct me if I am wrong.
The answer to the question is, 'a' and 'b'.
The reasons are,
Why D is an incorrect choice,
1. The entity bean is a CMP entity bean.
2. For CMP bean, the container handles the persistance of the data and ejbStore()(and also ejbLoad()) method/s are called by container (callback methods) to give the developer , some chance to do some work before persisting or after reading the data.
3. The life cycle events will be(considering the question),
entityBean.ejbActivate()---> entityBean.ejbLoad()---> entityBean.businessMethod1()---> entityBean.businessMethod2()----> entityBean.ejbStore()---> and then(container will extract the persistant fields from bean instance and will write to DB) ----> entityBean.ejbPassivate()
If the entity bean is a BMP, then answer 'D' is correct.
Why 'a' is a correct choice,
1. If the business methods were marked with 'RequiresNew' Tx attribute, the container would have started a new transaction for each business method while suspending the client's(the session bean's transaction); and what has mentioned in option 'c' would have happened.
So the business methods are not marked with 'RequiresNew' Tx attribute and hence 'a' is true.
Thanks,
Manish

hi Mano,
I have verified, by creating the same scenario, for Q. 28 (one BMT session bean and a CMP entity bean with 'RequiresNew' Tx context[throws RemoteException] ; and also 'Required' Tx context[throws TransactionRolledBackException]), that it exactly happens, as I have mentioned in my previous posting.
And if ICE gives the result of Q.28 as 'b','d' instead of just 'b', then it has a bug.
Thanks,
-Manish

hi All,
After reviewing the answers, posted, to the questions from the ICE test, I think the answer to the question '28' should be 'b'.
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".
The answer 'd' can not be true as the client (Session Bean) is receiving the TransactionRolledBackException exception. The 'TransactionRolledBackException' is thrown only when the bean executes in the client's transactional context and the bean has one of the following transactional attributes,
1.Required
2.Mandatory
3.Supports
Other way of looking at the option 'd' is,
if the bean has the 'Requires New' as the transactional context , container will always
suspend the client's transaction (if client has started one) and start a new transaction for the bean's method.
In case of a system exception, the container will,
1. roll back the bean's transaction.
2. throw RemoteException exception.
3. The client's transaction can resume and is un-affected.
Reference : Table 8, section : 12.3.1 (page: 191) in ejb_1.1_spec doc).
Please correct me, if I am wrong.
Thank you,
-Manish