About Question enthuware.oce-ejbd.v6.2.602 :
Moderator: admin
-
- Posts: 33
- Joined: Mon May 02, 2011 5:09 pm
- Contact:
About Question enthuware.oce-ejbd.v6.2.602 :
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");
}
}
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");
}
}
Re: About Question enthuware.oce-ejbd.v6.2.602 :
So the that it supports only two callback interceptor methods is wrong ?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
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!
thanks for your feedback!
If you like our products and services, please help us by posting your review here.
Re: About Question enthuware.oce-ejbd.v6.2.602 :
Please enlighten me on the subject of this question:
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?
Code: Select all
The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.
What about session beans, will their PreDestroy methods be called in case of their abnormal termination?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
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."Guest wrote:Please enlighten me on the subject of this question: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.Code: Select all
The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.
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.
No, not if a system exception is thrown from the bean (Section 4.6.3).What about session beans, will their PreDestroy methods be called in case of their abnormal termination?
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
Re: About Question enthuware.oce-ejbd.v6.2.602 :
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.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
Hi,
I like to join the movement that find the "destroyed" from the possible answer:
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
I like to join the movement that find the "destroyed" from the possible answer:
to fuzzy."The PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.".
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
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
This statement is straight from section 5.4.5:
-Paul.
Can't really argue with the specThe PreDestroy callback occurs at the time the bean is removed from the pool or destroyed.
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 22
- Joined: Thu Jul 25, 2013 3:39 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
Agree
Best Regards,
Mihai
Best Regards,
Mihai
-
- Posts: 38
- Joined: Fri Aug 16, 2013 11:37 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
"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?
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?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
Yes, please see Table 3 in section 4.8.6 of EJB 3.1 specification. It lists the methods you can call.sanju.ait@gmail.com wrote:"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?
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 9
- Joined: Sun Dec 07, 2014 3:27 am
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
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?
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?
-
- Site Admin
- Posts: 10043
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.oce-ejbd.v6.2.602 :
Yes, it could be called a bit ambiguous.
HTH,
Paul.
HTH,
Paul.
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 14 guests