Krum Bakalsky

Congratulations!

Instead of congratulating me, could you please kindly explain why you have erased my topic for the second time ?

Thanks!

Has anyone else had the same problems ?
I triggered a request to join the group, even sent a message to the group manager ..... but even a week later there is no response.
My results are present on the Sun certification database site.
Probably this is a dead group....

The JPA 1.0 specification says that the executeUpdate() method of the Query API must be executed within a transaction (a JTA or a resource-local one).
Otherwise an exception is thrown.

Using transactions in a critical part of the whole JPA 1.0 design. You cannot make database insertions without a transaction, even if you use simple EntityManager.persist() invocations, instead of executing queries.

Just because of curiosity, have you ever succeeded to make database insertions from a Java code, without transactions ? I could hardly believe that this is possible.

http://forums.netbeans.org/post-47321.html&highlight=

other people have had the same problems....

Hi Jack,

As far as transaction control is concerned, everything depends on the application needs.
In the majority of the cases, container-managed transactions should be chosen, since the
container takes care for a lot of things instead of you. If you use bean-managed transactions,
it is supposed that the developer understands well the JTA API and can achieve his needs
without the help of the container. In some books the authors even go further stating that
only very-experienced developers should use bean-managed transactions.

However, BMT is inevitable if you want, for instance, to trigger a transaction from the
web tier. CMT is only for EJBs. So there are scenarios when the developer to use a BMT
is the only possible way.

If you want an advice, please explain me exactly what you are trying to achieve.

(c) You can achieve a persistence context that will outlive the JTA transactions by two approaches:
using EXTENDED persistence context with a stateful session bean;
using application-managed persistence context (in JavaEE environment you can obtain such a one
through a @PersistenceUnit annotation).


(d) There is no problem not to start a transaction from the client. But you will have to explain your goals if you want to be advised which approach is more suitable.

(f) The deploy of the app client is complaining that most probably you have messed up the business interface types. Check them once again.
(If your app client lives in a separate JVM, then you must use remote interfaces only)

Take a look at this: http://stackoverflow.com/questions/848675/ejb-annotation-in-clients

Are you sure that you have declared correctly your client code as a valid application client ? (maybe this is done through some deployment descriptors, i don't know ) If the container does not recognize it as an app client, then dependency injection is forbidden and you must use look up instead.
http://javahowto.blogspot.com/2009/10/sample-application-clientxml-java-ee-5.html


Why don't you try to look up the remote interface in the client anyways, instead of having it injected ?


Something to add about the IDENTITY strategy:

Another difference, hinted at earlier, between using IDENTITY and other id generation
strategies is that the identifier will not be accessible until after the insert has occurred. While no
guarantee is made as to the accessibility of the identifier before the transaction has completed,
it is at least possible for other types of generation to eagerly allocate the identifier, but when
using identity, it is the action of inserting that causes the identifier to be generated. It would be
impossible for the identifier to be available before the entity is inserted into the database, and
because insertion of entities is most often deferred until commit time, the identifier would not
be available until after the transaction has been committed.

This is from "Pro EJB 3: Java Persistence API" book.

Some vendors offer implementations of joined inheritance without the use of a discriminator column.
Discriminator columns should be used if portability is required.

From "Pro EJB 3: Java Persistence API" book....

Why don't you use simple XSD validation of your ejb-jar.xml ? There are a lot of XML tools which support XSD validation.

As far as we are talking about duplicate inserts, i suppose that you are talking about "duplicate primary key" problems ?
In this case, you should just take care to specify an adequate primary key generating strategy for your entities.
You can choose TABLE or SEQUENCE.

The only problem will come when a transaction is rolled back, since it will detach your entities:

If there is a new entity that uses automatic primary key generation, there may be a
primary key value assigned to the detached entity. If this primary key was generated
from a database sequence or table, the operation to generate the number may have been
rolled back with the transaction. This means that the same sequence number could be
given out again to a different object. Clear the primary key before attempting to persist
the entity again, and do not rely on the primary key value in the detached entity.

From "Pro EJB 3: Java Persistence API"

Just to be clear:

As far as i can see, you are using container managed transaction demarcation, right ?
And you are using the default REQUIRED attribute, meaning that each method must be executed within a JTA transaction.
And you are using container-managed transaction scoped EntityManager, meaning that it's persistence context will live exactly as the JTA transaction lives.

I see that you are using an application client. Do you start a transaction from it ? In what transactional context do you invoke your findCustomer() business method ?
If the answer is "in none", then invoking this method will start a new transaction, but at the and the transaction will end, and the returned entity instance will be detached.
(Actually, it will be detached just because you are returning it through a remote business interface, meaning that it will be serialized by the container and deserialized at the client side)

Are you sure that you are using everything in the right way ?

Since you are passing your entities through a remote business interface, is your entity class implementing java.io.Serializable ?

From which book did you prepare JPA stuff ?

Hi, Abhay,

I definitely recommend you "Pro EJB 3: Java Persistence API" by Mike Keith, Merrick Shincariol, Apress.
In my humble opinion, this is the BEST book about JPA 1.0 out there....

Glad to know that my advice has helped you.

Didn't you just use the EJBInvoker job, which comes with the Quartz distribution ?

Congratulations !!! Your score is amazing !!!

I have already purchased Charles's book for 310-083 (the latest one) and i'm glad to know that it is OK to prepare you well for the exam.
But do i really need to dive into Head First ?!
I really want to 'eat' only one book for my preparation .... I'm tired of reading 5 different resources (as i did for SCBCD 5)...

Congratulations

And just one clue:
On the exam, there was a dedicated question to the javax.ejb.Init annotation.
I was shocked because i hadn't met it in any of my prep resources (but somehow managed to give the right answer - pure luck + intuition).
Make sure you know it !