About Question enthuware.oce-ejbd.v6.2.602 :

[max2fl]

Hi,

It supports only two call back methods: PostConstruct and PreDestroy.

from ejb3.1 spec:
5.4.7Timeout Callbacks
A message driven bean can be registered with the EJB timer service for time-based event notifications.The container invokes the appropriate bean instance timeout callback method when a timer for the bean has expired. See Chapter 18, “Timer Service”.

example:
@MessageDriven(
public class QueueListenerEJB implements MessageListener
{
//valid code........

@javax.ejb.Timeout
public void onTimeout() {
System.out.println("MDB onTimeout");
}
}

[Guest]

So the that it supports only two callback interceptor methods is wrong ?

[admin]

You are right, the option should make it clear that it is talking about "life cycle" call backs. Time out is not considered a life cycle call back. This will be fixed asap.

thanks for your feedback!

[Guest]

Please enlighten me on the subject of this question:

Code: Select all

The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.

I was sure that if a bean is _destroyed_, as in the case of throwing a system exception, then the PreDestroy is not called. I am not certain whether "remove from the pool" is covered in the specs at all. It may well be.

What about session beans, will their PreDestroy methods be called in case of their abnormal termination?

[admin]

Please enlighten me on the subject of this question:

Code: Select all

The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.

I was sure that if a bean is _destroyed_, as in the case of throwing a system exception, then the PreDestroy is not called. I am not certain whether "remove from the pool" is covered in the specs at all. It may well be.

It is. As per Section 4.6, "Note that a container can also invoke the PreDestroy method on the instance without a client call to remove the session object after the lifetime of the EJB object has expired."

Further, in Section 4.7.1, it says, "When the container no longer needs the instance (usually when the container wants to reduce the number of instances in the method-ready pool), the container invokes the PreDestroylifecycle callback interceptor methods for it, if any. This ends the life of the stateless session bean instance.

What about session beans, will their PreDestroy methods be called in case of their abnormal termination?

No, not if a system exception is thrown from the bean (Section 4.6.3).

HTH,
Paul.

[roxy]

I agree with "Guest" that the term destroyed is not very clear. When I saw the affirmation the first thing that came to my mind was destroyed because of an error so I didn´t choose that option. I understood the explanation given above, but still, I´m worried if at the exam it will appear situations like this that leads me to error.

[mopuffus]

Hi,

I like to join the movement that find the "destroyed" from the possible answer:

"The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.".

to fuzzy.
Here is my argumentation :The container calls the PreDestroy when it removes the bean instance from the pool. A bean can be destroy thru a lot of things (e.g. system exception) and the PreDestroy method may be not be call on "destroy-ment"
It is true that the answer uses the OR between the two options ("... removed from the pool or destroyed ...") and as long as at least one (OR) condition is true the answer is valid but IMHO this makes the answerer fuzzy.

IMHO this answer can be formulated like this:
"The PreDestroy callback occurs at the time the bean is removed from the pool and destroyed."
or
"The PreDestroy callback occurs at the time the bean is removed from the pool."

Best Regards,
Mihai

[admin]

This statement is straight from section 5.4.5:

The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.

Can't really argue with the spec

-Paul.

[mopuffus]

Agree

Best Regards,
Mihai

[sanju.ait@gmail.com]

"The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed. The PreDestroy lifecycle callback interceptor method executes in an unspecified transaction and security context."

Is it the reason that we can't access resource manager in stateful and stateless lifecycle interceptors callbacks?

Also, so can we access resource manager in singleton session bean lifecycle interceptors callbacks?

[admin]

"The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed. The PreDestroy lifecycle callback interceptor method executes in an unspecified transaction and security context."

Is it the reason that we can't access resource manager in stateful and stateless lifecycle interceptors callbacks?

Also, so can we access resource manager in singleton session bean lifecycle interceptors callbacks?

Yes, please see Table 3 in section 4.8.6 of EJB 3.1 specification. It lists the methods you can call.

HTH,
Paul.

[garfield]

Hello to everyone.
I have read the discussion so far and the conclusion for "The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed." is that unlike Session beans in which a System Exception forces the instance to be dropped without PreDestroy to be invoked; in MDBs the instance is dropped and PreDestroy is invoked!

The 'admin' has quoted the standard for this, but as of section "5.4.19 Missed PreDestroy Callbacks":
> The Bean Provider cannot assume that the container will always invoke the PreDestroy callback method (or ejbRemove method) for a message-driven bean instance. The following scenarios result in the PreDestroy callback method not being called on an instance:
> - A crash of the EJB container.
> - A system exception thrown from the instance’s method to the container.
> If the message-driven bean instance allocates resources in the PostConstruct lifecycle callback method and/or in the message listener method, and releases normally the resources in the PreDestroy method, these resources will not be automatically released in the above scenarios. The application using the message-driven bean should provide some clean up mechanism to periodically clean up the unreleased resources.

Is this a ambiguity in the standard or what?

[admin]

Yes, it could be called a bit ambiguous.

HTH,
Paul.