Arun Krishnamoorthy

Just to clarify, wouldn't the JNDI context be available under java:comp/env/UserTransaction instead of java:comp/UserTransaction?

If you are concerned only about pooled connections (database,resource manager etc), closing the pooled connection in each business method is a very good idea. Since these are pooled, the overhead for returning a connection back to the pool is minimal (just a local invocation on a method in the call stack).

If you are maintaining connectivity to some external legacy systems and it is imperative for you to hold on to your socket connections over multiple business method calls due to a huge overhead in reacquiring socket connections, you could set the socket connection timeouts while acquiring your socket connection. This would ascertain these resources being released even if the ejbRemove() method does not get called.

I think both of you are right...

Sandy...when remove() is called on the remote interface, ejbRemove() never gets called for a stateless session bean and hence, no RemoveException is thrown.

Sandesh...since stateless session beans do not have a primary key, calling remove (Object PK) would throw a RemoveException.

The answer is Yes for question A. I am not 100% sure on the JMS destinations NOT being passivated on question 2.

Yes, the CMT transaction suspends before the BMT transaction is started.
Transactions can never propagate into a BMT bean. BMT beans always execute under their own transactions.

No... a nested transaction would imply that there's a dependency between the CMT and BMT transaction but, there is no such relationship.

The BMT and CMT execute under separate,unrelated transactions.

The reason you cannot use the other three transaction attributes viz., Supports, Not Supported and Never is because entity beans are always transactional i.e. they have a meaningful transaction context. The other three transaction attributes allow (or enforce) the entity bean's method to run under an unspecified transaction context.

The reason why entity beans are always transactional is because they model shared, persistent business data (and methods that act on the business data). Since they (as in-memory objects) represent persistent data, they need to synchronize themselves with a persistent data store through calls to ejbLoad() and ejbStore(). The use of the ejbLoad and ejbStore methods for caching an entity object�s state (which is what an entity bean does) in the instance works well only if the Container can use transaction boundaries to drive the ejbLoad and ejbStore
methods. When one of the three attributes specified above is assigned to a remote interface or a home business method, the corresponding
enterprise bean class method executes with an unspecified transaction context. This means that the Container does not have any well-defined transaction boundaries to drive the ejbLoad and ejbStore methods on the instance.

Therefore, the ejbLoad and ejbStore methods become unreliable under the above scenario. This would result in a condition where the entity bean's in-memory state does not match the persistent data state which is highly undesirable.

Hope this helps...

Session Beans do not need an unsetSessionContext() since an ejbRemove() callback can be used to handle all clean-up code needed when moving from "ready" to "does not exist" state. For an entity bean, ejbRemove() causes the entity bean to go back to the pool only (the entity bean instance still exists in the jvm heap). If the pool size becomes too large, the container would still need to move this entity bean instance to the "does not exist state". Since the ejbRemove() callback CANNOT be used for the reason mentioned above, unsetEntityContext() callback was provided.

Session beans have no such need since ejbRemove() itself can handle the state transition.

I found this under the sun site (blueprints):

Why is there a restriction against using the Java Reflection APIs to obtain declared member information that the Java language security rules would not allow? Doesn't Java automatically enforce those rules?

Contrary to common belief, most of the Java Reflection API can be used from EJB components. For example, loadClass() and invoke() can both be used by enterprise beans. Only certain reflection methods are forbidden.


This restriction refers to the enabling of the security permission ReflectPermission. The suppressAccessChecks permission target name, when enabled, allows a class to use reflection to inspect, access, and modify protected and private members and methods in other classes. Obviously, if EJB components are using private or protected members or methods to manage sensitive information, this facility could be used to violate security mechanisms. Therefore, the EJB specification explicitly restricts usage of suppressAccessChecks, to prevent the security hole that would result. Denial of ReflectPermission is part of the standard security policy for an EJB container.

Hope this helps...

I think you misunderstood what I said...the stateless session bean is not trying to maintain conversational state in the example I gave you.
Variables in stateless session beans should ONLY contain state which can be used by any client instance and not state which is specifically stored for a specific client instance.

The socket connection in the bean instance remains the same for "ANY" client instance even though it may be used by multiple clients at different times. The purpose of the socket connection may be to send some information to the external system based on "parameters" (local variables) passed to the business method.

If I am still not clear, let me know...

I am not sure I agree with you...there could be instances where we may need to do something in ejbRemove() for a statless session bean. For example, consider that a stateless session bean needs to communicate with an external legacy system through Sockets from its business methods. Assume there is considerable overhead in attempting to make a socket connection to this external system. So, I would want to get a socket connection only once, use it in my business methods as necessary, and release the connection only when the bean instance no longer exists. You can acquire the socket connection in ejbCreate(). To release the socket connection, you would have to use ejbRemove() so that when the Container removes the bean instance, the socket connection is also released. Of course, if there's a system exception or if the container crashes, ejbRemove() would never get called and we would not release the socket connection [one way to handle this would be to set a timeout on the socket connection].

What do you think?

I want to clarify that although the original discussion is pertaining to ejbCreate(), the quote I added from that discussion is applicable to any method call using the component interface's stub on any client.

With that said, ejbRemove() gets called ONLY by the container for stateless session beans. It is not tied to the remove() call you make from the client through a home or component interface. The container calls ejbRemove() on its own prerogative...for instance, if a stateless session bean pool size is configured at 5 and there are 8 clients trying to make a business method call simultaneously. The container would make three additional stateless bean instances of that type (remember, session beans are non-reentrant) to enable processing of these business method calls. Once the business calls are done and the container is not using these additional three instances for a certain period of time, it would call ejbRemove() on the bean and then destroy the bean.

So, in conclusion, ejbRemove() for a stateless bean does get called only when the container needs to reduce the instance pool size.

Sorry... I sent out an incomplete response.

Refer to this response from Kathy:

https://coderanch.com/t/158485/java-EJB-SCBCD/certification/beanness-stateless-session-bean

Focus on this statement:

And remember, this is not a problem because all stateless beans of a certain type can use ANY EJBObject for that bean type, since every stateless bean of a specific type is the same as any other, and so it is the same with the EJBObject references for beans of that type.

So, the container has the option of preserving that EJBObject type if it deems appropriate and hence, would be an implementation detail. Note that its possible for the container vendor to have only ONE instance of EJBObject for a stateless session bean (not necessarily one for each client making a business method call).

Refer to this response from Kathy Sierra on a differnet question:

Shalini,

I found an excellent thread with regards to your question above (in case you don't already have it):

web page

Hope that clarifies.