Tony Docherty wrote:
But that last option doesn't end in ma.gif it ends in ma.1gif so can you please be more specific about exactly what is allowed.
With fetch="join" on a collection or single-valued association mapping, you will actually avoid the second SELECT (hence making the association or collection non-lazy), by using just one "bigger" outer (for nullable many-to-one foreign keys and collections) or inner (for not-null many-to-one foreign keys) join SELECT to get both the owning entity and the referenced entity or collection. If you use fetch="join" for more than one collection role for a particular entity instance (in "parallel"), you create a Cartesian product (also called cross join) and two (lazy or non-lazy) SELECT would probably be faster.
Kunal Lakhani wrote:Hemant Thard, it works. Thanks.
But, i really don't know why the code given by me doesn't works.
NonUniqueObjectException: a different object with the same identifier value was already associated with the session:
Nitin Gaur wrote:Came across this thread while searching JDBC vs JPA discussions.
I have batch application that fetches customer data (from multple tables), get it processed from an external app, stores the results back in same database (different set of tables). This batch has to run for around 100 thousand (100,000) customers.
We thought to use JPA with openJPA (sorry no hibernate) though no solid reason but it is proving to be slower than expected. Now, conteplating to switch to JDBC. Have not done JDBC test yet but inviting point of view if it is right approach?
If I use saveorupdate() instead of merge, it saves a new object,detaches the old object and attaches the new obj. to the session.