[ https://issues.apache.org/jira/browse/JUDDI-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alex O'Ree closed JUDDI-1004. ----------------------------- > JUDDI-3.3.7 With SQL Server Database Gives Primary Key Violation For Table > j3_category_bag > ------------------------------------------------------------------------------------------- > > Key: JUDDI-1004 > URL: https://issues.apache.org/jira/browse/JUDDI-1004 > Project: jUDDI > Issue Type: Bug > Components: core, juddi-tomcat > Affects Versions: 3.3.7 > Reporter: Amol Bhonsle > Priority: Major > Labels: jUDDI, juddi > Fix For: 3.3.9 > > > Our application is based on JUDDI-3.3.7 When we try to publishService() we > get following Exception: > > > Caused by: <openjpa-2.3.0-r422266:1540826 fatal store error> > org.apache.openjpa.persistence.RollbackException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > FailedObject: > [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7] > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:594) > at > org.apache.juddi.api.impl.UDDIPublicationImpl.saveService(UDDIPublicationImpl.java:892) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:179) > at > org.apache.cxf.jaxws.JAXWSMethodInvoker.performInvocation(JAXWSMethodInvoker.java:66) > at > org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:96) > ... 42 more > Caused by: <openjpa-2.3.0-r422266:1540826 fatal general error> > org.apache.openjpa.persistence.PersistenceException: The transaction has been > rolled back. See the nested exceptions for details on the errors that > occurred. > FailedObject: > [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7] > at > org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerImpl.java:2370) > at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2207) > at > org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2105) > at > org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:2023) > at > org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81) > at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1528) > at > org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:933) > at > org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:570) > ... 50 more > Caused by: <openjpa-2.3.0-r422266:1540826 fatal store error> > org.apache.openjpa.persistence.EntityExistsException: Violation of PRIMARY > KEY constraint 'PK__j3_categ__3213E83FD3C84046'. Cannot insert duplicate key > in object 'dbo.j3_category_bag'. The duplicate key value is (902). {prepstmnt > 1928491676 INSERT INTO j3_category_bag (id) VALUES (?)} [code=2627, > state=23000] > FailedObject: > [org.apache.juddi.model.ServiceCategoryBag@2a6330e7|mailto:org.apache.juddi.model.ServiceCategoryBag@2a6330e7] > at > org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4959) > at > org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4934) > at > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:134) > at > org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:76) > at > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:144) > at > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushInternal(PreparedStatementManagerImpl.java:100) > at > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flush(PreparedStatementManagerImpl.java:88) > at > org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flushPrimaryRow(OperationOrderUpdateManager.java:203) > at > org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager.flush(OperationOrderUpdateManager.java:89) > at > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:104) > at > org.apache.openjpa.jdbc.kernel.AbstractUpdateManager.flush(AbstractUpdateManager.java:77) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreManager.flush(JDBCStoreManager.java:732) > at > org.apache.openjpa.kernel.DelegatingStoreManager.flush(DelegatingStoreManager.java:131) > ... 57 more > Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Violation of > PRIMARY KEY constraint 'PK__j3_categ__3213E83FD3C84046'. Cannot insert > duplicate key in object 'dbo.j3_category_bag'. The duplicate key value is > (902). {prepstmnt 1928491676 INSERT INTO j3_category_bag (id) VALUES (?)} > [code=2627, state=23000] > at > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:219) > at > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:195) > at > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$1000(LoggingConnectionDecorator.java:59) > at > org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection$LoggingPreparedStatement.executeUpdate(LoggingConnectionDecorator.java:1134) > at > org.apache.openjpa.lib.jdbc.DelegatingPreparedStatement.executeUpdate(DelegatingPreparedStatement.java:275) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreManager$CancelPreparedStatement.executeUpdate(JDBCStoreManager.java:1792) > at > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.executeUpdate(PreparedStatementManagerImpl.java:268) > at > org.apache.openjpa.jdbc.kernel.PreparedStatementManagerImpl.flushAndUpdate(PreparedStatementManagerImpl.java:119) > ... 65 more > > We checked table j3_category_bag and it had previous data, and id with value > 902 was already present as previously we were on JUDDI-3.0.4 and we upgrade > to , but then why JUDDI did not select next sequence to assign value for new > record? Once we restart tomcat on which JUDDI is hosted, everything works > fine and as expected, a new value for id is automatically selected. But > ideally there should not be need to do tomcat restart and publish service > should work automatically. > Is there a possible issue of cache clearance for id generation? > > -- This message was sent by Atlassian Jira (v8.3.4#803005)