Paulus Maessen

Sandesh,

I would definitely go for the spec.

Maybe it's a missprint in HF EJB: because for sessionbeans you are indeed not required to include CreateException...

Sandesh,

Thank you for correcting me: I got the terminolgy mixed up.

- system exceptions may be re-thrown to the client, but only if they are explicitly included in the throws clause of the home/component interface

should read

- checked exceptions are re-thrown to the client, but only if they are explicitly included in the throws clause of the home/component interface

btw, this means that if an exception like java.sql.SQLException is declared in a throws clause it wil not be wrapped in a RemoteException

regards,

Paul

- SCBCD

Hi Peter,

Below as I understand it (it’s a bit lengthy, but you asked for it ):

If you are calling bean methods directly, or methods on other objects like e.g. SessionContext, exceptions are thrown as-is since the container is not involved. Just plain old Java.

If you are calling bean methods through the home/component interface however, the container cicks in and calls the bean method on behalf of the client. Now the following rules apply:

- if the bean method throws an application exception the container re-throws it as-is to the client
– if the bean method throws any other type of exception the container throws a RemoteException or EJBException or subclass thereof UNLESS the beans client started the transaction, in which case the container throws TransactionRolledbackException or TransactionRolledbackLocalException

An application exception is an exception that is declared to be thrown by the home/component method that is a (indirect) subclass of Exception but not of RuntimeException (+ some exceptions to this rule, see spec).

So:
- runtime exceptions like IllegalStateException and NullpointerException can never be application exceptions and the container will always throw Remote/EJBException when the bean throws such an exception.
- system exceptions may be re-thrown to the client, but only if they are explicitly included in the throws clause of the home/component interface
- If a bean method makes a call to a remote interface, any RemoteExceptions or subclasses thereof thrown from the remote method must be handled by the bean code because bean methods are not allowed to throw RemoteExceptions
- If a bean method makes a call to a local interface and the bean code doesn’t handle EJBExceptions or subclasses thereof : the container is required to throw a Remote/EJBException. I suppose that in the case of a local interface the container could just re-throw the exception, but I don’t think it is required to do so.

Hope this tidies it up,

Paul

- SCBCD

The finder method defined on the home interface returns (collections of) component interfaces.

The corresponding ejbFind... method on the *bean* return (a collection of) primary keys though.

The finder method defined on the home interface returns (collections of) component interfaces.

The corresponding ejbFind... method on the *bean* return (a collection of) primary keys though.

As I see it:

not A since it can be called from setSessionContext
not C since you are using CMT.
not B,H since they are not defined on *EJBContext* but on the subinterfaces

so I think the answer should be D,E,F,G

Hi Yamini,

if you haven't obtained a copy of the EJB specification from SUN you should because you can find it there:

1. Not all. The specification lists the callbacks that run in an unspecified transaction context.
2. Unspecified transaction context means that the specification doesn't demand anything from the container. Some containers may use a transaction, others may use no transaction at all.
3. No. See e.g. table in par. 7.6.1. I believe the container will throw a java.lang.IllegalStateException.

Hope this helps,
Paulus

Hi Nileesha,

The container must be able to store a reference ot the UserTransaction interface when passivating a bean, see the EJB specification, par 7.4.1.

Hi Shobha,

By home methods I mean the business methods that you can define on the local or remote home interface of entity beans, not the methods on the EJB(Local)Home itself.

These methods are implemented on the component interface of the bean (the ejbHome... methods).

Does this answer your question?

Hi all,

I have a question about the example in the SCWCD exam study kit:

On page 165, listing 10.7 shows a servlet that uses an instance variable to cache a database connection. As I understand it this is not threadsafe.

Right?

Home methods are used to implement business logic that is not related to a specific entity bean. You can't use EJB-QL for Home methods. You could implement a ejbSelect method on your bean though and call this method from within a Home method.

An ejbSelect method is not required to return references to entities, it may also return the values of a specific (CMP) field for entities satisfying certain criteria.

A Find method is used to obtain (a collection of) *references* to specific entities satisfying certain criteria, which you provide by means of EJB-QL.

The reason behind this is that it makes your bean code more open: if you would throw a RemoteException you can't expose the method in a local home/component interface.

If instead you throw a EJBException you can, if the interface is remote the container will wrap your EJBException in a RemoteException.