Sven Thor

I passed SCBCD last week with 95%. I studied specifically for the exam for approximately three months.

I used "Enterprise JavaBeans" by Richard Monson-Haefel in the preparations. I cannot say enough good things about this book and I highly recommend it to anyone who is preparing for SCBCD. It is easy to read, to-the-point and I think one of the most updated EJB books on the market (it covers EJB 2.1). It covers most of the topics you need to know for the SCBCD exam. Also, the book includes a JBoss workbook section with a lot of useful examples. I used JBoss and Ant when trying the examples in the book.

After studying this book for about two months going through Head First EJB for the final exam preparation was a breeze which took 4-5 days.

I used the SoftSCBCD exam simulator for the final preparations the last days before the exam. I scored between 85%-95% on the mock exams. The questions were very much like the questions on the real exam so I recommend it.

I used the EJB spec only for a couple of details.

Good luck!

Br,
ST

There are two things you should do in ejbPostCreate:

- establish relationships with other entity beans, you do this by initializing cmr-fields
- if necessary, pass a reference to your ejb object to other ejb's, you get a reference to your ejb object using ejbCtx.getEJBObject(). You should not use a this reference since clients should never talk directly to the bean object

Both these things cannot be done in ejbCreate() since the primary key is not yet available. So you have to do them in ejbPostCreate() instead.

Br,
ST

If you scroll down six posts in the topic list you will see that I posted the exact same question earlier today about the scenario "Client calls remove() on a bean that's already been removed" on p. 559 i HF EJB. I also don't understand it.

Why don't the client receive a NoSuchObjectException? From the replies I have read I still can't figure this out.

On the EJB object, or more precisely its stub, you can call remove(). I would assume this call to remove() to be treated as any other business method call. The way I understand "a bean that has already been removed" is that both the bean object and the ejb object are gone. So assuming the call from the stub reaches the container, the container will not find any ejb object to handle the remove() call. I would then think it should throw an NoSuchObjectException back to the client.

BTW, looking at the stack trace it seems like a NoSuchObjectException is thrown first and then wrapped in a RemoteException.

Br,
Sven T.

It's from an excercise where you are supposed to guess what kind of exception might occur for specific scenarios.

The scenario:
"Client calls remove() on a bean that's already been removed"

The explanation:
"You might be tempted to say RemoveException, but that's not it. Remember, remove() is just another method in the bean's interface, and if you call it on a removed bean, you'll get the same exception you'd see if you called any other business method on a removed bean - remote clients get RemoteException and local clients get EJBException."

I understand the part about not receiving a RemoveException. However, I thought this was a case for NoSuchObjectException or NoSuchObjectLocalException. I would assume they should be used instead of RemoteException or EJBException in the same way that the more specific exceptions ObjectNotFoundException and DuplicatKeyException are used instead of their more generic parent exceptions FinderException and CreateException when a single-ref finder/select fails or bean creation fails.

Can anyone clarify ?

Br,
Sven T.

In HF EJB on page 559, the first scenario, the question is what happens when a "Client calls remove() on a bean that's already been removed" ?

The answer according to HF EJB is that a remote client receives a RemoteException and a local client receives an EJBException. Why do these clients not receive the more specific exceptions NoSuchObjectException or NoSuchObjectLocalException respectively ? Or maybe they do ?

Br,
Sven T.

I have a question regarding remote vs local client view and EJBs.

My appserver (JBoss) seems to apply local communication also when I lookup the remote interfaces in JNDI. That is, the appserver seems to override my intention of using remote communication (RMI/IIOP) and use local communication instead. More specifically, I am able to pass non-serializable objects between EJBs and they are passed-by-reference.

Since I am working within the same EJB container (JBoss installed on my laptop) it is of course OK to use local communication.

Has anybody else had similar exeperiences ? Is this the case also for other appservers ?

Br,
ST

I can not see that the <reentrant> element in the deployment descriptor makes any difference for entity beans. That is, I am able to reenter an entity bean even when <reentrant> is set to False. Is this default jboss behaviour ? If so, can it be overridden ?

The same goes for session beans which can also be reentered. They do not have en <reentrant> element and I would have thought the default behaviour to be False.

br,
ST

There was an error in the code in the previous post.

utx.commit() was supposed to be commented out:

... //THIS WOULD SOLVE THE PROBLEM //utx.commit(); ..

Does anybody know why the container throws a TransactionInProgressException when met1() in the following bean is called ? I am trying to define transaction demarcation within the bean using the JMS API.

I know that the problem can be avoided by using commit|rollback in JTA instead of using commit|rollback from JMS. I just don't understand where the transaction is started. The transaction-type element in the deployment descriptor is Bean, so the container should not start a transaction when met1() is invoked.

Perhaps one should best avoid using commit|rollback from JDBC and JMS alltogether when one writes code which executes inside an EJB container?

Br,
Sven T.

import javax.ejb.*; import javax.naming.*; import javax.jms.*; import javax.transaction.*; public class TransABean implements SessionBean{ public SessionContext ejbCtx; public Context jndiCtx; //business methods public void met1(){ System.out.println("TransABean::met1"); try{ //Define queue javax.jms.Queue q = (javax.jms.Queue) jndiCtx.lookup("java:comp/env/jms/scbcdQueue2"); //Get factory object QueueConnectionFactory qcf = (QueueConnectionFactory) jndiCtx.lookup("java:comp/env/jms/QueueConnectionFactory"); //Create connection QueueConnection qc = qcf.createQueueConnection(); //Create transacted session QueueSession qs = qc.createQueueSession(true, 0); //Create sender QueueSender qsnd = qs.createSender(q); //Create message TextMessage tm = qs.createTextMessage("msg"); //THIS WOULD SOLVE THE PROBLEM //UserTransaction utx = ejbCtx.getUserTransaction(); //utx.begin(); try{ qsnd.send(tm); qs.commit(); } catch(Exception ex){ qs.rollback(); } //THIS WOULD SOLVE THE PROBLEM utx.commit(); //Close connection qc.close(); } catch(NamingException ex){ ex.printStackTrace(); } catch(JMSException ex){ ex.printStackTrace(); } catch(Exception ex){ ex.printStackTrace(); } } //create public void ejbCreate(){ //System.out.println("TransABean::ejbCreate()"); } //ejb public void setSessionContext(SessionContext ejbCtx){ //System.out.println("TransABean::setSessionContext()"); this.ejbCtx = ejbCtx; try{ jndiCtx = new InitialContext(); } catch(NamingException ex){ ex.printStackTrace(); } } public void ejbPassivate(){} public void ejbActivate(){} public void ejbRemove(){ System.out.println("TransABean::ejbRemove()"); } }

I am somewhat confused by the term distributed transactions.

Case 1: Your application consists of two EJBs running in separate VMs. There is only one database involved so the two phase protocol is not required. If the first EJB starts a transaction and then calls a method in the second EJB which uses transaction attribute Required, then the transaction context must be propagated between the EJBs.

Case 2: Your application consists of several EJBs all running in the same VM. Transactions running in the application might span different databases and/or message servers. This means that a transaction manager and the two phase protocol is needed for commit and rollback operations.

Which of these cases best fits the term "distributed transaction" ? I guess my question is what decides whether a transaction is distributed or not, the application itself being distributed (requiring RMI or something similar) or the fact that the application works with more than one resource manager (requiring use of the two phase protocol ?

I ask because I am not sure how to interpret statements such as this one about the embedded transaction manager in JBoss (from "Java Transaction Processing"): "...the current implementation does not support distributed transactions (although it is JTA compliant)...".

Br,
ST

Thanks.

I am using JBoss. I am not able to find any info in the log files.

ST

It says in the EJB spec (about CMT) that for entity beans and session beans there are certain methods that must be assigned transaction attributes. However, the <assembly-descriptor> part of ejb-jar.xml is optional. And the appserver I am using does not complain or give a warning when I deploy a set of beans without the <assembly-descriptor> part.

How does the container know which transaction-attributes to use? Does it use default configuration or no transactions at all ?

Br,
Sven

In Enterprise JavaBeans by Monson-Haefel it says on page 78 about entity beans:

"Although it is not required by the EJB specification, some J2EE application vendors insist that ejbCreate() throw a javax.ejb.CreateException..."

However, 10.6.4 in the EJB2.1 specification says about entity beans, "The throws clause must define the javax.ejb.CreateException..."

Can anybody clarify this point for me ? Is it a MUST for ejbCreate() to throw CreateException ?

BR,
Sven Thor

This book is excellent for SQL and RDBMS:

http://www.amazon.com/exec/obidos/tg/detail/-/0764525840/qid=1120830612/sr=8-3/ref=sr_8_xs_ap_i3_xgl14/002-0015180-3359256?v=glance&s=books&n=507846

Br,
Sven T.

I would like to learn in more detail how the virtual machine actually works. Anybody read or know of a good book on this topic which they would like to suggest ?

From what I can find on Amazon most books on this topic are quite old. For instance I found this comparison of three books on the topic but it is from 1998 so I don't know how relevant they are today:

http://www.javaworld.com/javaworld/jw-03-1998/jw-03-bookreview.html

Any suggestions ?

Br,
Sven T.