Hello, from time to time i encounter such exception:
"More than one row with the given identifier was found: DeploymentPK@40f5ce59, for class: OwsmServicesDeployment"
I'm using hibernate 3.3.1.GA as JPA realization and ehcache as 2-nd and 3-rd(query) level caches.
Most interesting that exception occurs not alwaus but rarely and without obvios connection to external conditions, i mean i can query same query 10 times and can get or not this exception (Sooth to say, i cant reproduce it on test environment).
I'm using rather simple configuration of my entities without any joins or relations (but data is taken from db view - not from table):
Entity Deployment:

}
And id:

And query that causes error:

I don't expect that anybody will help me with exactly this situation, but i want to ask some questions:
1) As i've seen in hibernate code, this exception occurs at method

I wasn't able to trace what's happening furter in hibernate code, so i want to ask if this method tries to hit the cache?
2)Is there some probability that 2 or more same records could be placed in cache at some conditions? (i'm using memory and disc cache) Can memory and disc cache conflict in some way?
3) Can it be that 2 different queries that query same entity may conflict?
I've been told that exception started to occur after disc cache was set. But i've searced, googled, and nowhere was able to find any references regarding such conflicts.
Can anybody share some suggestions about my situation or answer any of my questions please? (sorry for my english)

One thing that I find curios about your mapping is that the embeddable cannot manage the primary key fields because the insertbale/updatable are set to false on both the Deployment and the DeploymentPK.

I would remove those attributes from the DeploymentPK like this:



and then also remove these fields from "Deployment" entity:



You can access those from the entity identifier anyway.

The problem that you reported happens when you have a Department in your Session, and you try to add a new one using saveOrUpdate or update.
If that's not the case, you need to write a reproducible test case for it and submit it as a bug report, as it might be some issue.

I would suggest trying to update to a new version of Hibernate and see if it reproduces because you are running an old version: 3.3.1.GA.
Maybe there was an issue at some point and it got fixed.

I think it's not about update or insert - these entities are not managed to be updatable or insertable and are taken from the database view. All interactions that involve described entities represented by 2 queries:

and

that are results of webservice method invocation, through the EJB dao like:
@SuppressWarnings("unchecked")
@Override
public List<DeploymentAbstract> getDeployments(String code, String sid) {
return entityManager.createNamedQuery("DeploymentBySIDandCode")
.setParameter("sid", sid)
.setParameter("Code", code)
.getResultList();
}

First, please follow the suggestion of mihalcea_vlad, because your mapping is wrong
Second, change your query to be

So you only use them to query the database. In that case it could be something related to the cache, especially if you use two stores for the same 2nd level cache. It could be that there is a synchronization issue and from time to time, the same entity is tried to be pushed from the 2nd level cache into the 1st level cache from two different cache stores and the 1st level cache prevents registering the same entity twice.

Try using a single cache store. EHCache supports in-memory caching with overflowing to disk, but it's just one cache store.

Sorry, i mean i already use in-memory cache with overflow to disk.

In this case, it could be some synchronization issue.
I think it's worth trying out with a newer Hibernate version and see if the problem persists.
Hibernate 3.3.1 is from 2008 and even if it's a bug, you get a better chance of getting a fix on 4.x or 5.x versions.

This make me confused, the 1st level cache "org.hibernate.engine.StatefulPersistenceContext" use these two fields to cache all the objects

How could it retain duplicated objects?

It cannot hold duplicates but it throws an exception if somehow there is an action which would want to re-associate an entity that's already managed.