Shreyas Reddy

Thanks for the reply. But i think i didn't make my question clear
someMethod() has two parameters which are not being used within the method body. My original post has complete method definition as i found it. I just changed the method names. The method comments say the parameters are optional, sometimes they could be null. But within the method body since the parameters are not being used, are not they redundant? Can we not safely remove the paramters as shown below



/** * blablabla * @param component the component returning from (optional) REMOVED * @param map Map which contain the return values if any (optional) REMOVED */ public void someMethod() { anotherMethod(); }
I hope i was clearer this time. If not I will try to explain again.
thanks

I was reviewing someone else's code recently and came across a method defined as below(Method names have been changed...)

/** * blablabla * @param component the component returning from (optional) * @param map Map which contain the return values if any (optional) */ public void someMethod(Component component, Map map) { anotherMethod(); }

Though the comments indicate the reason for having the two parameters, i really don't understand how they are being used. Is not the scope of the parameters limited to the someMethod() body? I haven't seen the anotherMethod() definition yet, but i believe it shouldn't matter.
Can someone help me understand this?
Thanks in advance

Just for clarification...
for session and message driven beans resources are released in ejbRemove()
But for entity beans, ejbRemove is used to actually remove the entity in the persistant store and unsetEntityCtx is used to release resources- when the bean is removed from the pool. Did I get it right?
Please explain if not so...
thx

SessionBean interface has setSessionContect(...)
MessageDrivenBean has setMessageDrivenContext(...)
EntityBean has setEntityContext(...) and unsetEntityContext(...)

Why does only entitybean have the callback method to unset its entitycontext? WHy not sessionbean and messagedrivenbean?
thx,

The explanation from Kathy might help at this link
https://coderanch.com/t/159878/java-EJB-SCBCD/certification/stubs-client

SLSB dies(does not exist anymore) at the Container's will or when the bean throws a system(unchecked/uncaught) exception.If the bean is removed by the container beacuse the pool size is too big or some other reason then ejbRemove() is called by the container before the bean dies. If the bean dies because of a system exception then ejbRemove() is not called and the system resources are not freed.
As you said, ejbCreate and ejbRemove are the places to connect and disconnect to DB.
Someone answer this --If a system exception is thrown, how do we free the resources?

What happens in the following scenario?

Method bar() of BMT bean1 starts transaction(tx A)
bar() calls method foo() on CMT bean2
foo() marks tx A for roll back by calling EJBContext.setRollbackOnly()
foo() returns
bar() calls commit() on tx A (suppose bar() didn't check if the tx was marked for rollback by foo())

Does bar() throw RollbackException or any other exception?
I hope the question made some sense.
Thanks,

THe SLSB does not maintain CLIENT SPECIFIC state. It can have it's own instance variables and state(not client related) which can be used while processing client's requests. Client should never rely on state of the bean.

Everytime a client sends a request, the container picks a bean from the pool, process clients request and return the bean to the pool.
In your case, probably the same bean was picked for multiple calls from the client(ur container might have had only one bean in the pool-just a possiblity).

Unlike stateless session beans a pool is not maintained for stateful session beans. SFSB are created as the requests for the new beans come in.
Here is the flow for SFSB creation. I hope it helps:

client calls create on home
container makes EJBObject and session context
container constructs bean instance and links the bean to its ctx and ejbobject
container sends the client a stub to the ejbobject
...
...business methods invocation
...
client calls remove on either componenet or home interface
container calls ejbREmove on the b ean
container kills the bean and EJBobject
THE BEAN IS KILLED

As per my understanding, when a client calls remove on a Stateless SB, the client is just indicating that she/he is done witht he bean and will not be able to use the EJB Object reference anymore. The container throws an exception if you try to use the reference once you call remove.
The container does not remove the bean and does not call ejbRemove when the client calls remove. The container removes the bean whenever it likes depending on its implementation.

To answer ur question simply, the ejbRemove is not called when client calls remove for a stateless session bean.

This page says if the client calls remove(Object primarykey) on a session bean, then the client will get a RemoveException.
THE API documentation says the client gets RemoteException...
Which one is correct?
...........
public void remove(java.lang.Object primaryKey)
throws java.rmi.RemoteException,
RemoveExceptionRemove an EJB object identified by its primary key.
This method can be used only for an entity bean. An attempt to call this method on a session bean will result in a RemoteException.

...........

When a client calls remove on an entity bean EJBObject, and if the database is down, is it considered as system failure resulting in RemoteException or will it result in RemoveException?
Thanks,

I would vote for M:Supersize Me
For some reason that picture made me feel - learning design patterns from this book as as coooooool as eating out in fast food place.

If a stateless session bean doesn't really care when remove() is called, and as per page 282 of HFE nothing happens to the bean when client calls remove(), how come an exception is thrown if the client tries to use the EJB reference after removing the bean? Isn't removing the bean same as calling remove on the bean?

I have a home ref
I call create on home ref
I call bus method on component interface
then i call remove --> nothing really happens
i call bus method on component interface --> does this throw an exception?
thx,

For a finder method returning a collection of component interfaces, if no entities matching the criteria are found an empty collection is returned. When does such a method throw FinderException?
Thanks,