Emil Kirschner

100% is not a score you see very often - congratulations!

Originally posted by Byron Estes:
Emil,
I appreciate the time you took explaining why you feel that "C" is a correct answer.
But...
Ponder this for a moment. Unlike stateful session beans or entity beans which are trully assigned to a client for some period of time. Stateless session beans because they have no state and are therefore considered to functionally equivalent don't really get assigned out of the pool. The container using the request interceptor mearly delegates the method call to to an available bean and returns.
Because it's never assigned, in my mind it never leaves the pool. It just performs the method. The next call from the client may go to the same stateless session bean or a different stateless session bean. It doesn't matter because they have no "identity or state".
Thoughts? Differing understandings/opinions?
Regards,

Byron,
you're right, the scenario you describes is perfectly possible and would be a very good implementation of the specs. However, the container provider is not forced to do it this way. The specs say "...the container MAY delegate requests from the same client within the same transaction to different instances and MAY interleave requests from different transactions to the same instance...". It may, it doesn't have to. This means the container implementor is free to do whatever he wants.
In your case, the object is still taken out of the pool, it just happens within each invocation. Your local proxy sends the request to the container, the container checks the object out of the pool, calls the method, releases the object back to the pool. this could be very efficient if the bean is called once per transaction and you have allot of transactions going on.
I agree that the implementation you described may be most efficient one.
There are situations, however, when I would like to keep instance out of the pool during the entire transaction. This may be if methods of a bean are called multiple times during the same transaction. obtaining / releasing the object each time can be costly, cos operating on a pool usually implies locking.
I have no ideea how different containers implement the specs. I guess most would do it as you described. I'll have a look at the JBoss sources, maybe I'll manage to figure it out.
Also the specs say: "the client may call create() and remove() WITHOUT NECESSARILY creating or removing instances". But it may. We cannot generalize.
So if you call remove, generally speaking, you cannot predict what happens. You may for a specific container, but not for all of them.
Does anyone have more info on how all this is implemented?
cheers,
e.

Originally posted by Byron Estes:
The answer is �D�. This is completely at the discretion of the container which may choose to physically destroy the instance or not.
Answer �A� is incorrect because the container may opt not to destroy it.
Answer �B� is incorrect. All Stateless session beans are equivalent and maintain no conversational state. They can be used by any client at any time.
Answer �C� is incorrect. This is a bit of a trick question. The instance may be destroyed, but the instance never really leaves the pool, so it can�t really be returned to it. In reality, any client can call any method on any EJB Object in the method ready pool.
Answer �E� is incorrect. The session instance could be destroyed. Also see answer �C� for explanation regarding �instance pools and stateless session beans�.
Answer �F� stateless session beans don�t have conversational state and are not passivated. This only applies to stateful session beans, not stateless session beans.

Hey,
C in very tricky indeed.
Assume you have a reference to a bean and then you release it. In some cases depending on the management algorithm, when you release the bean some condition may be met which would trigger the container to re-dimension the pool.
ex: you configure your pool to hold min 20, max 50 instances, with a trashhold of 5/10. this means that if you release a reference and there already are 9 free, 10 will become free and the container will reduce the pool size by 5 - means it will let the garbage collector remove 5 instances - have no ideea which ones.
now you can say that the reference is always released to the pool and the pool will shrink a few cycles later or you can say that the instance to which you hold a reference will be destroyed if some internal trashhold level is reached. Fact is, you have absolutely no ideea, since this is not written in the spex. each container provider can do this as they see fit.
all this given, hmmm, I think it's safe to say that the bean to which you hold the reference will either be returned to the pool or be destroyed depending on the pool's internal state at the moment when you release the reference (that is, when you call remove() ).
so in my opinion, C is actually a good answer.
cheers,
e.

Originally posted by JiaPei Jen:
How can a transaction be coordinated with legacy systems or Java systems outside the container/server?

in order to access a legacy system you need some sort of connector. If you want your connector to enlist with ongoing transactions in your app-server, the connector must be JTA complient, meaning that the classes that represent resources (like a jdbc connection) in your legacy system must implement javax.transaction.xa.XAResource and the manager / factory that allow you to obtain those resources must ba capable to detect ongoing transactions and enlist your resource with it.
Most commercial connectors are JTA complient but you can find situations (like when connecting to an AS400 queue using JTOpen) when you'll have to implement transaction aware access classes yourself.
Of course if you use a JCA compliant connector all becomes much more simple.
Cheers,
e.

Originally posted by SPAD:
The returned Enumeration/Collection has the remote references that doesn't neccesarily mean that the corresponding beans have been created. The beans may be in passivated state [no resource usage] and will be activated only in case of business method invocation. Check this out in Monson's book on EJB "The Life Cycle of Entity Bean" on I think page #213 secod ed

I definitely agree. I was talking about what happens on the server side.
e.

Congratulations! in which centre did you pass, if I may ask?

Originally posted by Frederic Vermaut:
At my return from holiday , I was pleased to note that I succeeded parts II and III with 91%
The result went pretty fast : I passed partIII on July 3rd and the result was posted on July 15th !
I had 95% for the first part.
I lost most of the points... guess where... in the class diagram (36/44). Component diagram (43/44) and sequence diagrams (12/12).
Thanks to all the people who participated in this forum.
Frederic
SCEA

Originally posted by Nicky Moelholm:
Hi,
If you want better reuse of your user session handling you put it in the Stateful session bean. The latter makes it possible to use the logic from Swing clients etc.

or from ejbs. you cannot access a http session maintained by a servlet from an EJB.

Originally posted by Emil Kirschner:

it means that the EJB spex do not allow you to create a server socket and listen to it (the create/bind/listen/accept sequence) and that is beacause the thread that listens for connections on your socket would block until a connection comes in and this would prevent the app server to properly manage the available pool of threads. basically, a thread is blocked without anything usefull happening there, which is a waste of resources.

I meant that in the context of an EJBean.

Originally posted by JiaPei Jen:
Thanks for the reply. Again, I have read somewhere says that "socket server is forbidden by EJB". I do not understand. Could anybody kindly explain it?

it means that the EJB spex do not allow you to create a server socket and listen to it (the create/bind/listen/accept sequence) and that is beacause the thread that listens for connections on your socket would block until a connection comes in and this would prevent the app server to properly manage the available pool of threads. basically, a thread is blocked without anything usefull happening there, which is a waste of resources.

Originally posted by Rahul JG:
In an Entity Bean, if a finder method returns a large number of records (say
thousands of them), will thousand bean instances be created? If yes, what
happens if the number of bean instances required to be created exceed the
number of instances which have been specified to be maintained in the pool?
I know this question would have been asked many times in many forums, but I
haven't been able to get a convincing reply. Can anyone answer me?

IMHO: If the pool is big enough and you have enough memory and there is only one active session, I guess it could load everything (unless it uses lazy loading).
But even if the pool is big enough and all the instances would fit in the ammount of memory you have, some of your beans may still be discarded (not loaded) since the container may need to load other beans or it may choose not to discard another bean in order to be able to load yours.
Since you're not accessing your beans all at once, the container can swap it quite nicely. But exactly how all this happens is very implementation dependent.
Keep in mind that in a real world scenario you may have multiple sessions accessing sets of beans in the container. it depends on your app's design, on the user's behavior, on the number of users and mostly on the algorithm the container implements.
Also, consider that the user may interact with your application is a very ramdom way.
Given all these parameters, I don't think it is possible to predict how your beans will be loaded / discarded.
Cheers,
e.