Charlie A

+ Follow
since Apr 17, 2005
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 Charlie A

Yes.. Ugender is absolutely correct ..
EJB Spec just expects the container to return the Home/Remote Object stub to the client, it is upto the container vendor how they deal with this.
Hey Joy,

You are right

The question is missing the word 'not'.. Good Catch!!

Does the spec specify which methods can be accessed and which cannot?

Yes, the Spec provide these details. Please refer the tables in Pg-80,90 of the spec.
Good Question.. I am breaking my head to find a answer for this..
Can you write down the procedure, how you tried to set the environment variable for CLASSPATH? Hope some output can come out of it..
Just corrected the typo error of the previous blog

Only in Stateful session beans(BMT), in ejbCreate(), you can access UserTransaction methods, but not all the methods. UserTransaction methods are not avaible in stateless** session beans, since there is no client associated with the bean, during creation.


Thanks for posting a good question.

HFEJB mentions that
'setting rollbackonly' and getting the status of rollback(CMT) cannot be done in ejbCreate (thro' SessionContext) whereas these operations could be performed using 'UserTransactions' in BMT.

You can call the getUserTransaction() method in ejbCreate(), for both Stateful & Stateless session beans (BMT beans only). The return type of this method will be an object of type UserTransaction.

Only for Stateful session beans(BMT), in ejbCreate(), you can access UserTransaction methods, but not all the methods. UserTransaction methods are not avaible in session beans, since there is no client associated with the bean, during creation.

The Spec says (Pg- 81):

Additional restrictions:
The getRollbackOnly and setRollbackOnly methods of the SessionContext
interface should be used only in the session bean methods that execute in the context of a transaction.
The Container must throw the java.lang.IllegalStateException if the
methods are invoked while the instance is not associated with a transaction.

So it is confirmed that you cannot call setRollBackOnly() methods in ejbCreate(), irrelevant of whether the bean is stateful/stateless or CMT/BMT.

You can refer the tables in page 80 & 90 of the spec.

Arun has covered most of the things.. I would like to add some more examples to it.

Consider that you own a Online Book Shop, and you need to provide the following functionalities
1) Purchase a book
2) Update the customer's email address
3) Insert/Delete/Query books in the database.
4) Send weekly e-magazines to your subscribed customers

Stateful Session Beans
Functionality 1 is provided by the SFSB. Consider that a customer adds a book in his shopping cart, and then looks for the other books. Then he comes back and checks his shopping cart. If he finds it to be empty, it will be total mess. To avoid these issues, we go for a stateful session beans, which retains the conversational state with the client.

Stateless Session Beans
Functionality 2 is provided by the SLSB. Customer updating the email address is a one time request and it is not required for the bean to remember the client's previous conversation.

Entity Beans
Functionality 3 is provided by the Entity Bean. Entity Beans generally represent a row in database table. It can combine data from mutliple tables, but as of now leave this. You can do the same task with normal JBDC, but you need to look after the transaction management, security and all other stuffs, which your container already provides for the entity beans.

Message Driven Beans
Functionality 4 is provided by the MDB. This is basically an asynchronous communication.

I feel the answer mentioned in the HFEJB is correct; i.e. answer - d only

Option C is bit tricky, you need to interpret it carefully.

c) The provider must close any database connections before ejbPassivate() completes.

Thumb Rule :
The Stateful session bean will successfully passivated if we ensure that all the non-transient variables must one of the following -
1. Serializable Object
2. a null value
3. bean's remote component interface or home interface
4. bean's local component or home interface
5. a SessionContext Object
6. Object of type JNDI Context
7. UserTransaction interface type
8. Resource manager connection Factory (like javax.sql.DataSource instance)

Closing the database in option C, implies something like conn.close();
It is good to call the clean up methods in the methods ejbPassivate() and ejbRemove(), but it is not a MUST. Here the option C fails..

I hope this might have cleared your doubt.
I hope that you have set the CATALINA_HOME and JAVA_HOME environment variable. If not below is the procedure to do it.

1. Right Click "My Computer", select Properties.
2. Click 'Advanced' Tab
3. Click 'Environmental Variables' Button
4. Under 'User Variables XXXX' frame, click the New button
5. Give the Variable name as 'CATALINA_HOME' and values as the root directory of the Tomcat folder eg: 'C:\jakarta-tomcat-X.X.X'
6. similary add a new variable called 'JAVA_HOME' and give the value as jdk root directory eg:- 'C:\j2sdk1.4.2_11'
7. Now reboot the machine, and start using your application.
Congrats Govinda.. 98% Rocking..
Congrates Barry !
17 years ago
Yes Jeroen is correct. To the existing classpath , just also add the directory path you want to place your classfiles
Simple.. Just a fundamental rule you need to remember

"Stateless session beans can neither be created nor can be removed, by the clients, but it moves in and out of the pool"

Stateless session beans totally lives on the mercy of the container. So when the client calls the remove() method, the container will just put back the bean into the pool. If the container feels that its lacking resources, it just kills few of the beans in the pool.
Yes all these methods focus on removing the beans. You can remove the bean either via home or component interface.

As you might be aware that there will be only one home for several bean instances of same type. Each bean has its own component interface tied to it. Suppose if you want to remove a bean using home interface methods how will you make the container identify the particular bean ? Since many bean instances are tied to the same Home Object. So we pass argument to identify the bean.

For session beans we pass the Handle as arguement and Object for Entity beans. Invoking the method remove(Object key) will delete the particular entity (row) fron the database.

In EJBHome
void remove(handle h)
void remove(Object key)

remove() method in EJBObject can be used by both Entity and Session beans

In EJBObject
void remove()