Sunil Patil

+ Follow
since Feb 05, 2003
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sunil Patil


If you want to test this what you can do is write a servlet.In that servlet first check if instance of stateful session bean exists as session attribute and if yes use it or else create new instance and store it in session. Once you get instance of bean call methods on it.
After deploying this servlet try to refresh the page calling servlet repetadly so that it gets multiple requests.

I have Oreillys java servlet programming book and this is what it says.

Somehow you browser should understand how to interpret response it is getting this can be done in one of the two ways.
1) You can required user to tell you the character set in case of browser it can be done by view encoding setting and user can try different character set till the response(display) makes sense for him
2) You can set charset in content-type header

I am not very sure if this is helpful to you at all
I am not sure if your talking about encoding or character encoding. Because i think there is no relation in char-set and encoding but there is relation between char-set and charencoding
encoding - is the transformation that happens on complete content while sending it from server to client. examples are like compression.In case if you want to write a image to output stream then also you need to do output encoding
char-set - Once you get content it will be big stream of bits.So you will use char character set encoding to find out what char-set is used say it may be UCS-2 then you can treat 2bytes as character if it is UTF-8 then character can be 1 to 3 bytes.
So you will read those many bytes in content and try to find out displayable character for it in corresponding conversion table for that character.
Hope this helps

So in the jar file for that kind of bean, there will be both remote and local interfaces - 2 files and (local) home interfaces another 2 files and 1 bean class file will total 5 files for that bean? How about the deployement - DD for that kind of bean? Is it diff or the same with regular bean?

In deployment descriptor you will have to declare both local-home,home,remote and local interface.
But in case if you want to use local inteface of the EJB you have to add ejb-ref in user bean with interface type as local and get reference to this bean from beans context (
In case of Entity bean it will be Container managed transaction so there wont be case of client starting transaction
Database write will be done once ejbCreate() is executed and before ejbPostCreate() because in ejbPostCreate() you will be able to take care of ejb-relationships(This you can not do unless there is record in parent table) and you need to have primary key set before your ejbCreate() method execution completes.
Hope this helps
I agree with you.
I am not sure if we can compare JTA/JTS with enterprise beans for technology supporting transaction isolation.
Even though ejbs provide transaction isolation level they use Transaction service provided by container for that which will be confirming to JTS. So only thing ejbs are doing is calling methods of Transaction service
Hi Sundeep,
In EJB 1.0, the first release of EJB, the ejbCreate() method in container-managed persistence was declared as returning void, while the ejbCreate() method in bean-managed persistence returns the primary key type. However, in EJB 1.1 it was changed to the primary key type, with an actual return value of null.
EJB 1.1 changed the return value of ejbCreate() from void to the primary key type to facilitate subclassing; i.e., to make it easier for a bean-managed entity bean to extend a container-managed entity bean. In EJB 1.0, this was not possible because Java doesn't allow you to overload methods with different return values. Changing this definition allowed a bean-managed entity bean to extend a container-managed bean, which in turn allowed vendors to support CMP by extending a container-managed bean with an automatically generated bean-managed bean´┐Ża fairly simple solution to a difficult problem.
1. Stateless session beans :
Is an EJB Object created everytime a home interface's create method is called? and Is the same EJB Object destroyed when the client calls remote interface remove() method?...Can EJBObjects be shared by clients at different times?
In case of stateless session bean creation and removal of bean's is detached from clients create() and remove() call.Container keeps pool of beans and takes a bean out of pool only to serve a business method.
So when client calls create() a EJBObject is created and client gets stub for that EJBObject.But container attaches a bean to EJBObject only when client calls a business method.
2. Message Driven beans:
Same questions as above.
Message driven beans do not have client view so they dont have EJBObject.
3. Entity beans:
Same questions as above. But if the client never calls remove() method(say, he does not want the data to be deleted from the database), when does the associated EJBObject get destroyed?
I am confused about this. In HFEJB on some pages author says that if more than one clients are trying to access same Entity then they will share EJBObject and on other pages i can see different EJBObjects sharing same entity bean. But i guess EJBObject can not be shared.
4. Stateful session beans :
Let me guess. There could be a new EJBObject created and destroyed whenever client calls home interface remove() method and remote interface's remove() method. But the EJBObject still remains attached to the client, even when the bean instance has been passivated?
EJBObject and bean is created and removed when client calls create() and remove().
EJBObject is not passivated because what will happen if client calls business method on passivated bean.EJBObject will be there and it will tell container to activate bean.
Hi Scott,
Transaction will always be either commited or rolled back at the end of the method call in case of CMT.
As per EJB Specs. 19.6.1 and 19.6.2 as client call to ejb will be using IIOP as wire protocol which is capable of carrying security and transaction information along with method call(Thats why in case of EJB IIOP is preferred over JRMP as wire protocol).
Now if you want you can lookup transaction service from JNDI in web or application client and start a transaction and then call EJB in that case ejb will participate in transaction which is allready started.

If the bean throws application exception, container throws exception to client but does not rollback transaction. What can client do if it was CMT bean (remember CMT transaction ends when the method ends?). So what we will get... we pass control to the client and the transaction is still not rolled back? How can that be with CMT?

What i understand is in case of CMT if you dont throw System exception and dont call setRollbackOnly() then container will commit the transaction when method ends. In case of CMT it is not possible for transaction to be in a state other than commited or rolled back by the time client gets control.
EJBMetaData inteface was introduced because developers wanted access to meta information about bean which is available to normal java class through reflection but was not available to EJB clients because of remote access to EJB.
In case of local client this problem is not there.You can directly use reflection.
Hi James,
As far as i know Tomcat is Servlet Container and it does not have a EJB Container.So i guess your deploying your EJB in Reference implementation or some other EJB server and trying to access it from application deployed in Tomcat.
In that case Tomcat will have its own Context which will be different from EJB Containers Context and when you do Context initContext = new InitialContext(); in Tomcat you will get Tomcat's context which will be different from EJB Containers Context where name Advice is registered for AdviceBean.
I had tried deploying both Servlet and EJB in Reference implementation and it works fine.
Hi Kathy,
Thanks for writing such a nice book on EJB's Head First EJB.
In the Client View chapter(page 121) you are saying that "The javax.rmi.PortableRemoteObject.narrow() method runs code written by the server vendor".But as PortableRemoteObject is part of JSE1.4 so i am not sure about how can it can run any code written by vendor.
In the JSDK help what it says for PortableRemoteObject.narrow() is "Checks to ensure that an object of a remote or abstract interface type can be cast to a desired type."
So if the home stub returned from the JNDI lookup is not implementing the home interface it will throw ClassCastException
Thank You
If i define both Local and Remote interfaces for a EJB which one is used when i try to invoke it through
a) Java client
b) Another EJB in same server
What are rules for this