Sandesh Tathare

Thanks to all you guys n gals for your support. Special Thanks to Kathy and Bert (HF Team). I found HF Book as really very good. Alongwith same, I referred to EJB specification. Thanks to ejbcertificate.com site for providing objective wise test.

My Advice to others would be read HF and Specs. Both are required. I missed 1 question from JMS. I must confess, it was a tough one to solve, as neither HF book nor Specs covered it fully to the best of my knowledge. Still feel very good today to have a lovely score.

Thanks to all you guys n gals for your support. Special Thanks to Kathy and Bert (HF Team). I found HF Book as really very good. Alongwith same, I referred to EJB specification. Thanks to ejbcertificate.com site for providing objective wise test.

My Advice to others would be read HF and Specs. Both are required. I missed 1 question from JMS. I must confess, it was a tough one to solve, as neither HF book nor Specs covered it fully to the best of my knowledge. Still feel very good today to have a lovely score.

Jyothi,

IMO, option 2 is correct against 1:

2. The client can safely continue the transaction by retrying the operation if an application exception is received, but only after checking the transaction has not been marked for rollback.

Option 1 says: The client can safely continue the transaction by retrying the operation if an application exception is received. But if EJBContext.setRollbackOnly() has been called before throwing application exception, even if client continues transaction it will not commit. So it's a good idea for a client program to check whether transaction has been marked for rollback and then safely continue.

Note: A lot depends on how one interprets word safely here. If we say safely means without any exception, yes then option 1 also makes sense. But while answering above question I interpreted safely means that it's safe to continue transaction and probability of transaction being rollback is less.

Please correct me if I am wrong.

Mark,

You are correct. The question is ambiguous. Question must clarify about transaction context of Bean method as either of following:
1] Bean method runs in context of the caller�s transaction
2] Bean method runs in context of a transaction that the Container started immediately before dispatching the business method.
3] Bean method runs with an unspecified transaction context.


The exception thrown by Container would differ based on the above mentioned. Client would receive javax.transaction.TransactionRolledBackException, if business method has transaction attribute as either Required, Mandatory, and Supports in this case.

So what transaction attribute is specified for business method on a bean must have been specified in question.

Rest assured. Actual Certification test would not have such ambiguous questions as per my past experience.

Sandy,

client will never get this type of Exception even if the client call
remove() on stateless session bean.

Client would get RemoveException, if client calls remove(Object PK) on Stateless Session Bean. I have tried this out.

Sandy,

I think you are talking about java.lang.IllegalStateException.

Note that java.lang.IllegalStateException is runtime exception and not a checked one. So one is not required to declare it in throws clause.

Kyle,

my guess is it will never get RemoveException for session bean.

RemoveException for Session Beans is thrown in following cases:

1] Because session objects do not have primary keys that are accessible to clients, invoking the javax.ejb.EJBHome.remove(Object primaryKey) method on a session results in the javax.ejb.RemoveException.
(Refer to section 6.3.2 Removing a session object of EJB 2.0 specification)

2] Because session objects do not have primary keys that are accessible to clients, invoking the javax.ejb.EJBLocalHome.remove(Object primaryKey) method on a session results in the javax.ejb.RemoveException.
(Refer to section 6.4.2 Removing a session object of EJB 2.0 specification)

3] If a session bean instance is participating in a transaction, it is an error for a client to invoke the remove method on the session object�s home or component interface object. The container must detect such an attempt and throw the javax.ejb.RemoveException to the client.
(Refer to section 7.6.4 Restrictions for transactions of EJB 2.0 specification)

Remember, RemoveException is declared in throws clause of following methods:
EJBHome:
1] remove(Handle handle) and
2] remove(Object primaryKey)

EJBLocalHome:
1] remove(Object primaryKey)

EJBObject:
1] remove()

EJBLocalObject:
1] remove()

Hope this helps.
[ November 17, 2004: Message edited by: Sandesh Tathare ]

Howdie All,

Just got a confirmation from www.ejbcertificate.com Team. They would be updating question appropriately.

I was appearing for Mock test for "Exceptions" on www.ejbcertificate.com site. I came across following question, where correction is required IMO:

Question:
Which of the following statements are true when a session bean's client receives a java.rmi.RemoteException? [Check all correct answers]
1. The client will never receives a java.rmi.RemoteException.
2. The client calls the session bean from another JVM.
3. The client calls the session bean from within the same JVM.
4. The container throws a java.rmi.RemoteException if the container performs a transaction rollback.
5. The throws clauses of all methods in the remote home and component interface must declare a java.rmi.RemoteException.

My Answer:You have answered: 2 5 - This is incorrect

Correct Answer:Answer 2, 4 and 5 are correct.

Explanation:The Container catches a non-application exception; logs it (which can result in alerting the System Administrator); and, unless the bean is a message-driven bean, throws the java.rmi.RemoteException (or subclass thereof) to the client if the client is a remote client, or throws the javax.ejb.EJBException (or subclass thereof) to the client if the client is a local client.

My Explanation:Answer 4 is NOT correct. I am aware that there are scenarios when Container performs transaction rollback and throws a java.rmi.RemoteException.However, we can NOT make a generic statement as The container throws a java.rmi.RemoteException if the container performs a transaction rollback.

Container can throw RemoteException and need not rollback transaction (if bean method runs in unspecified transaction context). So one can not say that whenever container throws a java.rmi.RemoteException, container performs transaction rollback.Please refer to 2nd row of Table 15 on page no. 376 of EJB 2.0 Specification.

Container can rollback transaction in case EJBContext.setRollbackOnly() is called before throwing an Application exception by a bean method. Container throws Application Exception to client as it is after it performs transaction rollback. So one also can NOT say that if Container rollbacks transaction, it will always throw a java.rmi.RemoteException.

Please correct me if I am wrong.

Dilip,

When transaction started by BMT is rollback, transaction started by CMT will not be rollbacked and it will continue once BMT method call is completed.

Puba,

When a Stateless SessionBean's ejbCreate calls getCallerPrincipal() on the SessionContext, it will throw java.lang.IllegalStateException.

When a bean executes a method that has no transaction context, i.e. Never. Can the bean access the security context of the client (session and entity beans)?

Are you referring to whether client can invoke EJBContext's following methods:
1] getCallerPrincipal()
2] isCallerInRole(java.lang.String)

Thanks for referring me to page 103 of HF EJB.

But then this triggers thought that either this is a bug or possibly Container is doing some things which we (Bean Providers) don't know. Possibly container is reusing EJB Object from 1 client to some other, once client calls remove. But then at least client 1's further business requests should lead to Exception. This is all messed up now.

:roll:

Well it's really funny. It actually worked like what you have said. I was expecting java.rmi.NoSuchObjectException.

I also tried removing EJBObject using EJBObject.remove() method, but there's no change in result. The business method runs fine.

I referred to Object Interaction diagram under Section 7.9.3 Client-invoked remove() of EJB specification, but there's no clarity imposed by Specification whether the EJBObject is killed by Container or not. In case of Stateful Session Bean, Container kills bean and EJB Object as per diagram on page 209 of HF EJB.

I think as below:
In case of Stateless Session Bean EJB Container Provider has freedom to provide implementation on what to do with EJBObject after receiving remove call from EJBObject Stub.
As we all are aware, Container provider is not required to kill bean instance, as it returns to pool after completion of business method. So Container Provider is least bothered about providing any handling when remove call is received from stub of Stateless Session Bean. Possibly Container provider has forgot that he/she is required to kill EJB Object reference. This could simple be a BUG or there could be totally different story to it.

Please refer to page 98 of HF EJB. It states as:

Each client gets his own EJBObject reference and his own bean. The client never shares a bean with another client, although the meaning of "shares" depends on whether the bean is stateful or stateless.

So I am arriving at a conclusion as:
Clients share EJBObject in case of Stateless Session Bean.

Please correct me if I am wrong.

Hi All,

The answers provided by ejbcertificate.com was wrong. Today I received confirmation from their end. They have updated their database accordingly.

Thanks ejbcertificate.com team for providing lovely site for testing our knowledge.