Description of problem:
Customer has fresh Oracle, JON Server (2.4.1) and JON Agents installations and after some time the following ERROR is logged:
2011-07-11 19:08:02,919 WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 1, SQLState: 23000
2011-07-11 19:08:02,919 ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-00001: unique constraint (JON.RHQ_PACKAGE_VERSION_IDX) violated
2011-07-11 19:08:02,919 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
This is followed by:
2011-07-11 19:08:02,939 WARN [org.rhq.enterprise.server.content.ContentManagerBean] There was probably a very big and ugly EJB/hibernate error just above this log message - you can normally ignore that. We detected that a package version was already created when we tried to do it also - we will ignore this and just use the new package version that was created in the other thread
AS explained in: https://bugzilla.redhat.com/show_bug.cgi?id=536070 the above error messages can be ignored. However, it doesn't look good to have all those ERRORs logged in the log file under normal conditions.
Looking at https://bugzilla.redhat.com/show_bug.cgi?id=536070#c9 it seems that there is nothing we can do at the moment to change this but we should try to get rid of them (in case when everything works fine) in a future.
Version-Release number of selected component (if applicable):
Lets review if this is still intractable
there isn't much we can do here because the exception is logged by hibernate.
This code needs to be executed fast (because this potentially is storing logs of packages) so we don't want to run into problems slowing down by doing a "check the DB if it exists, if not, THEN persist". We just persist and if we hit problems, we see if its not "really" a problem at that point. Besides, if we do the "check if it exists, if not, persist" we STILL aren't guaranteed that it will work - due to the multi-threadedness, we could concurrently have committed a new package after the if check but before the persist so the same issue occurs.
To avoid seeing the log messages, we'd have to turn that category off in log4j (in that case, we never see those errors if they legitimately happen elsewhere in the code) or we'd have to somehow refactor this code to avoid persisting a package version that was concurrently committed but yet not slow things down.
In my opinion, this is a low priority, low severity issue.