[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c... ] Olaf Lenzmann commented on HHH-1460: ------------------------------------ IMHO, this should return null. The current behavior is inconsistent and confusing at best - effectively it makes the behavior of the ORM statefully dependent on what read-access has been done in the same transaction before find() is called. This means that you cannot rely on getting null if you try to find an entity with an id that does exist for the type, but you have to be prepared to swallow an exception. Since something like a method exists( Class type, Object id ) does not exist (at least not in EJB3, where we ran into this behavior), checking for the existence of an entity requires us to write wrappers that redirect class-cast exceptions to a false result. If you really believe that this makes sense, please document this behavior clearly! The very simple fix would be to make DefaultLoadEventListener.loadFromSessionCache() check the actual type of the entity it finds in the cache (if that's possible based on the data at hand). Alternatively, the current behavior would be perfectly ok if there was an exists() method that works properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira