Tang Yue

Thank you guys! I am a college student and have all the time of the world. I think that's why I can do it so quickly.

I have no prior knowledge of EJB. I spent 8 days learning from sratch and passed it with 91%.
First I read EJB in action in 3 days. Then I read the study guide with reference to the specs. After that, I purchased Enthuware and my test results are:
Test 1 64%
Test 2 70%
Test 3 70%
Test 4 77%
Test 5 75%

I got about 75% in sun's assessment test. ETS really helped me a lot. Although my mock results weren't good, the 305 questions really covered every aspect of the exam so that in the real test, I found several questions very similar to mock ones.

Thanks Enthuware, and the support from this great community.
My next goal is SCJD.

If select x from X x, Y y
The comma in the "from" clause is equivalent to an Inner Join or a pure Cartesian join?

In ETS test 5 Q.62:
Consider the following JPQL:

select c from Customer c, IN(c.orders) o

What will this query return?


The correct answer is :
All Customers who have at least one Order.

Because the query is translated into
"For Sun Java Application Server and MySQL, select c from Customer c, IN(c.orders) o actually gets translated to :
SELECT DISTINCT t0.ID, t0.LASTNAME FROM CUSTOMER t0, ORDER t1 WHERE (t1.CUSTOMER_ID = t0.ID)
"

But in EJB in action, the book says one can perform theta join using ',' in the "from" clause.

I am totally confused.

When a CMT message-driven bean with REQUIRED attribute rolls back a transaction but no exception thrown, will the message be redelivered?
The answers of the 2 questions seem to be contradictory.

In Enthuware Test 4 Question no.49:
"
Consider the following code occuring in a MyBean code. It updates the database and sends a message to a queue named Q1. The message driven bean (not same as MyBean) associated with the queue requires a transaction and updates the database upon receiving a message.

11. public void myBeanMethod()
12. {
...
21. UserTransaction ut = ejbContext.getUserTransaction();
22. ut.begin();
23. queueSender.send(message); //sends a message to a queue Q1.
24. stmt.executeUpdate(query1);
25. ut.rollback();
...
30. }

Assuming that all the variables are properly defined and used, what will happen if the MDB associated with the queue Q1 rolls back the transaction but does not throw any exception?
"

The correct answer is "Neither the message is sent nor any database changes get committed."

The explanation says
"
In this case, the sending of the message is a part of MyBean's transaction. Therefore, if it rollsback the transaction, the message will not be sent.
The message will not be redelivered because it was never sent!
"

HOWEVER, in Test 4 Question No.51, the correct answer is "The transaction started by the MDB is rolledback and JMS Message redelivery semantics will apply."

Hello,Kristel
You mean, any class file found in the root of the persistence unit, or the subdirectories of the root of the persistene unit is evaluated?

UserTransction manages JTA transactions while EntityTransction is responsible foir resource-local transactions.
What if this happens:
ut.begin();
et=em.getEntityTransaction();
et.begin(); // what happens here? an IllegalStateException? Or the outer transaction is suspended?
...

In Enthuware, there is a question:
"
A persistence archive file named ejbplusPU.jar contains the following files:

com/enthu/ejbplus/Account.class
com/enthu/ejbplus/Person.class
META-INF/persistence.xml
META-INF/orm.xml

Given that Account and Person classes contain all the mapping information in the form of annotations, which of the above files will always be examined by the container when this jar is deployed? "

My answer is "persistence.xml" and "orm.xml", but no class files.

But the correct answer includes those class files.

According to persistence spec, "Any annotated managed
persistence classes found in the root of the persistence unit are added to the list of managed persistence classes."

Here, Account.class and Person.class aren't at the root of the persistence unit, so why should they be examined?

Of course it is relevant.
These annotations are used in SqlResultSetMapping of native sql query.

Is @Entity equivalent to @ENTITY ?

Is @PersistenceContext(type=EXTENDED) equivalent to @PersistenceContext(TyPe=exTenDed) ?

Oops, I paste the full text of that quote here:
"
EntityExistsException
The EntityExistsException may thrown by the persistence provider when the persist operation is invoked and the entity already exists. The EntityExistsException may be thrown when the persist operation is invoked, or the EntityExistsException or another PersistenceException may be thrown at commit time. "

Oh! Suddenly I understand...

I don't know what does @ColumnResult mean? It would be so nice if somebody explains this example in the persistence spec for me:
"
Scalar result types CAN be included in the query result by specifying the @ColumnResult
annotation in the metadata.
Query q = em.createNativeQuery("SELECT o.id AS order_id, " +
"o.quantity AS order_quantity, " +
"o.item AS order_item, " +
"i.name AS item_name, " +
"FROM Order o, Item i " +
"WHERE (order_quantity > 25) AND (order_item = i.id)",
"OrderResults"
);

@SqlResultSetMapping(
name="OrderResults",
entities={
@EntityResult(
entityClass=com.acme.Order.class,
fields={
@FieldResult(name="id", column="order_id"),
@FieldResult(name="quantity", column="order_quantity"),
@FieldResult(name="item", column="order_item")
}
)
},
columns={
@ColumnResult(name="item_name")
}
)
"

In persistance spec 3.7:
"
The EntityExistsException may thrown by the persistenc
operation is invoked and the entity already exists. The E
thrown when the persist operation is invoked, or the Enti
PersistenceException may be thrown at commit time. "

But in the study guide:
"
For a given entity A, the persist method behaves as follows:

If A is an existing MANAGED entity, it is IGNORED. However, the persist operation
cascades as defined below. "

Isn't the two contradictory? If one invokes persist(A) where A is a managed entity and surely already exists, will this persist() be ignored or an EntityExistsException be thrown?

"Object ref = jndiCntx.lookup("java:comp/env/ejb/TravelAgent");"

This client use a local jndi lookup. But How can the container for this client(on another machine) locates the remote bean?

As far as I know, the client should use a global lookup like " jndiCntx.lookup("TravelAgent/Remote") "

But why the example doesn't use a global lookup?

In Oreilly EJB 3.0 20.4.2 "JAVA EE Application Client Components", there is an example:
public class MyJavaEEClient
{
private static @EJB ProcessPaymentRemote processPayment;
public static void main(String [] args) {
InitialContext
jndiCntx = new InitialContext( );
Object ref = jndiCntx.lookup("java:comp/env/ejb/TravelAgent");
TravelAgentRemote bean = (TravelAgentRemote)
PortableRemoteObject.narrow(ref,TravelAgentRemote.class);
Customer cust = new Customer( );
cust.setName("Bill");
bean.setCustomer(cust);
TicketDO ticket = bean.bookPassage(...);
}
}


The book says
"Notice that the client component did not need to use a network-specific
JNDI InitialContext. In other words, we did not have to specify the service provider in order to connect to the Java EE server. This is the
real power of the Java EE application client component: location transparency . The client component does not need to know the exact
location of the Ship EJB or choose a specific JNDI service provider; the JNDI ENC takes care of locating the enterprise bean."

But exactly how does the JNDI ENC take care of all these?
If the parameters of InitialContext() are not specified, how does the program locate the remote bean ProcessPaymentRemote? The book doesn't mention jndi.properties either.

Does this client has its own ENC?


In short, this is too magic for me...