query.getResultList(); <= contains the same instance X times

[fbadt]

The code has a call to "query.getResultList();" The returned List has 10 entries for the 10 rows in the database; however, Each of the 10 entries in the List is the same instance reference. This is the first entered row in the DB. There should be 10 difference references to 10 EJBs. What could cause this? I don't see any open or closed bugs on this issue. JBoss 4.0.4 and 4.0.5 give the same behavior. Note: the rows are populated by a stored procedure in the same transaction as an insert is made to a "request" table.

[monkeyden]

When I had that problem it was an incorrectly defined primary key. The key(s) I specified didn't represent exactly one row. I also saw that all of the non-primary key fields had the same value, but the primary key field itself was null.

[fbadt]

In this case, there can, and often will, be more than one row that should be returned by getResultList (thus the use of this method not getSingleResult)

The lookup is not done by PK. It is done in a where clause like the below. There should be 10 rows / elements in the result; and there are 10. The problem is that all 10 are the same reference instead of 10 references corresponding to 10 rows returned:

select v from TABLE1 v where v.SOMEGETTER = ?1

[jblackmore]

Do you have any collections on that entity? Are you using EJBQL with joins? I think I stumbled over a related scenario, except I'm calling 'getSingleResult' and getting an exception that there are 6 or 8 or 124 elements. No code or queries or even data changed since 4.0.4 in my case, and this just started happening after moving to 4.0.5.

I think the problem is that there may be only one instance of TABLE1 but 10 of some mapped OneToMany collection of your entity. I used a SortedSet instead of the default List (generated by Hibernate tools) to eliminate dups in 4.0.4, but that approach doesn't seem to do the trick any more. The other thing you can do is wrap the result list with a LinkedHashSet, to eliminate dups and preserve the order. It occurs to me that this is all part of the "paradigm mismatch", but I feel like I shouldn't have to do that, Hibernate should. But it works.

Please see this post for my "fix" that got me from 4.0.2 to 4.0.4, but now I have to go back into every EJBQL query invoked throughout the system and wrap it with a LinkedHashSet. Sigh, job security. :-)

/index.html?module=bb&op=viewtopic&t=82946&start=10

Anyone know a better solution?

[fbadt]

Turns out what was thought to be the PK column was not. A PK on a sequence table was created and the former "pk" was used to group results on a common value.