Enthuware

Posted: **Sun Nov 04, 2012 5:28 am**

I agree with the answers, only that I am trying to see how two parts of the ejb specs come together in this answer:
For each dependency injection of a stateless session bean in another component, a new instance of the injected bean is created.

On this piece of specs you would say: a new instance is not created everytime

3.4.7.2 Stateless Session Beans
All business object references of the same interface type for the same stateless session bean have the same object identity, which is assigned by the container. All references to the no-interface view of the same stateless session bean have the same object identity.
For example,
@EJB Cart cart1;
@EJB Cart cart2;
...
if (cart1.equals(cart1)) { // this test must return true
...
}
...
if (cart1.equals(cart2)) { // this test must also return true
...
}

But on the other hand in chapter 16.2.1 Sharing of Environment Entries the following is stated:

Each injection of an object corresponds to a JNDI lookup.

and

In general, lookups of objects in the JNDI java: namespace are required to return a new instance of the requested object every time. Exceptions are allowed for the following:
•The container knows the object is immutable (for example, objects of type java.lang.String), or knows that the application can’t change the state of the object.
•The object is defined to be a singleton, such that only one instance of the object may exist in the JVM.
•The name used for the lookup is defined to return an instance of the object that might be shared. The name java:comp/ORB is such a name.

On this part of the specs you would say: a new instance is created everytime

The only way I can combine the two pieces of specification is that for a Stateless Session bean the rule applies
"The container knows that the application can’t change the state of the object."

What do you think?

Regards,
Frits

Posted: **Sun Nov 04, 2012 8:36 am**

Hi Frits,
I think the third exception, "The name used for the lookup is defined to return an instance of the object that might be shared." is also be applicable here. Conceptually, a stateless session bean is shared among multiple client and that is why equals method returns true for any two instances of the same stateless session bean. So it is entirely possible that two different client may get the same instance of the stateless session bean object.

HTH,
Paul.

Posted: **Sun Nov 04, 2012 10:20 am**

Hi Paul,

Yes you are right, it might also fall under the third exception....

Regards,
Frits

Posted: **Sat Feb 08, 2014 9:14 pm**

The last option says that one or more remove method can be defined. In such case, where there are more than one such methods, which one will get called?

Also, the explanation given in the last line :

Also, note that if the bean is in a transaction when its remove method is called, it will throw RemoveException and the bean will not be discarded.

will it be true even if retainIfException=false?

Posted: **Sat Feb 08, 2014 10:18 pm**

1. The one called by the client will be called.
2. Yes, it will not be discarded because as per section 8.5.10.5

The container treats the RemoveException as any other application exception. See Section 14.3.

And as per Section 14.3, application exceptions do not cause a bean to be discarded.

Posted: **Sun Feb 09, 2014 9:48 pm**

But looking at the definition of retainIfException, it doesn't differentiate between system and application exception.

http://docs.oracle.com/cd/E17802_01/pro ... xception()

boolean retainIfException
If true, the stateful session bean will not be removed if an exception is thrown from the designated method.

Doesn't it mean that if any exception is thrown and if "retainIfException=false" , bean instance will be discarded when a call is made to @Remove method?

Thanks,

Posted: **Sun Feb 09, 2014 9:56 pm**

The problem is that the specification says what happens when retainIfException is true. But nowhere does it say what happens when it is false. It doesn't even say whether retainIfException is meant to override the default behaviour in case of application exceptions.

So, to be honest, I am unable to answer this question with 100% certainty.

HTH,
Paul.

Enthuware

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

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :

Re: About Question enthuware.oce-ejbd.v6.2.597 :