[jBPM] - The external Trigger makes the transition from subprocess node to the next node while subprocess is active.
by Felix Jose
Felix Jose [http://community.jboss.org/people/FelixKJose] created the discussion
"The external Trigger makes the transition from subprocess node to the next node while subprocess is active."
To view the discussion, visit: http://community.jboss.org/message/548693#548693
--------------------------------------------------------------
Hi All,
I was using the "*SubProcessDocument.jpdl.xml"* and "*SubProcessReview.jpdl.xml*" from the "examples\src\org\jbpm\examples\subprocess\outcomeactivity" given in the jbpm-4.3 examples. In my sample program I have done
*ProcessInstance processInstance =**+executionService+**+.startProcessInstanceByKey("SubProcessDocument");+*+** + *+assertNotNull(processInstance.findActiveExecutionIn("review"));+*** *+processInstance = executionService.signalExecutionById(processInstance.getId());+*
+*executionService*+
*.findProcessInstanceById(processInstance.getId());*+*assertNotNull(processInstance.findActiveExecutionIn(*+
+*"next step"));*+
**
+So the transition is happend from *"review"* to *"next step"* instead of waiting for the output from the *SubProcessReview* subprocess.+
+Is this an expected result ?+
+or whether the main execution should not be able to transition from subprocess state to next state untill and unless the subprocess execution is completed?+
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548693#548693]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[JBoss Web Services CXF] - Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9
by Andrew Dinn
Andrew Dinn [http://community.jboss.org/people/adinn] created the discussion
"Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9"
To view the discussion, visit: http://community.jboss.org/message/548690#548690
--------------------------------------------------------------
The XTS tests are still seeing some failures on the latest AS trunk with cxf stack 3.3.1.SP1. I think they all appear to stem from a single issue which relates to dispatch of soap faults. It's not actually CXF's fault handling which is the problem. The XTS code uses its own JaxWS based service to dispatch faults -- I know that sounds weird but I'll explain that in a minute. Anyway, the problem is not actually to do with the dispatch, routing or receipt of the soap faults, it's to do with creating the relevant JaxWS service. This is a WSDL first service defined as follows:
> <?xml version="1.0" encoding="utf-8"?>
> <!--
> a specification for a service which can be used to dispatch a SOAP 1.1 SoapFault
> to an arbitrary client
> -->
> <definitions
> xmlns:s="http://www.w3.org/2001/XMLSchema"
> xmlns:tns="http://jbossts.jboss.org/xts/soapfault"
> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> xmlns:wsaw="http://www.w3.org/2006/02/addressing/wsdl"
> targetNamespace="http://jbossts.jboss.org/xts/soapfault"
> xmlns="http://schemas.xmlsoap.org/wsdl/">
> <types>
> <s:schema>
> <s:import namespace="http://schemas.xmlsoap.org/soap/envelope/"
> schemaLocation="http://schemas.xmlsoap.org/soap/envelope"/>
> </s:schema>
> </types>
> <message name="SoapFault">
> <part name="fault" element="soapenv:Fault" />
> </message>
>
>
> <portType name="SoapFaultPortType">
> <operation name="SoapFault">
> <input name="SoapFault" message="tns:SoapFault" />
> </operation>
> </portType>
>
>
> <binding name="SoapFault_SOAPBinding" type="tns:SoapFaultPortType">
> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
> <operation name="SoapFault">
> <input message="tns:Soapfault">
> <soap:body use="literal"/>
> </input>
> </operation>
> </binding>
>
>
> <service name="SoapFaultService">
> <port binding="tns:SoapFault_SOAPBinding" name="SoapFaultPortType">
> <wsaw:UsingAddressing required="true"/>
> <soap:address location="http://localhost:9000/interopat/SoapFaultService"/>
> </port>
> </service>
>
>
> </definitions>
>
I generated code from this WSDL using wsconsume (well, actually, I think I generated it using Glassfish's wsimport but essentially it is the same thing) as follows:
> @WebServiceClient(name = "SoapFaultService", targetNamespace = "http://jbossts.jboss.org/xts/soapfault", wsdlLocation = "wsdl/soapfault.wsdl")
> public class SoapFaultService extends Service
> {
> private final static URL SOAPFAULTSERVICE_WSDL_LOCATION;
> private final static Logger logger = Logger.getLogger(org.jboss.jbossts.xts.soapfault.SoapFaultService.class.getName());
>
>
> static {
> URL url = null;
> try {
> URL baseUrl;
> baseUrl = org.jboss.jbossts.xts.soapfault.SoapFaultService.class.getResource(".");
> url = new URL(baseUrl, "wsdl/soapfault.wsdl");
> } catch (MalformedURLException e) {
> logger.warning("Failed to create URL for the wsdl Location: 'wsdl/soapfault.wsdl', retrying as a local file");
> logger.warning(e.getMessage());
> }
> SOAPFAULTSERVICE_WSDL_LOCATION = url;
> }
>
>
> public SoapFaultService(URL wsdlLocation, QName serviceName) {
> super(wsdlLocation, serviceName);
> }
>
>
> public SoapFaultService() {
> super(SOAPFAULTSERVICE_WSDL_LOCATION, new QName("http://jbossts.jboss.org/xts/soapfault", "SoapFaultService"));
> }
> /**
> *
> * @return
> * returns SoapFaultPortType
> */
> @WebEndpoint(name = "SoapFaultPortType")
> public SoapFaultPortType getSoapFaultPortType() {
> return super.getPort(new QName("http://jbossts.jboss.org/xts/soapfault", "SoapFaultPortType"), SoapFaultPortType.class);
> }
> /**
> *
> * @param features
> * A list of {@link javax.xml.ws.WebServiceFeature} to configure on the proxy. Supported features not in the <code>features</code> parameter will have their default values.
> * @return
> * returns SoapFaultPortType
> */
> @WebEndpoint(name = "SoapFaultPortType")
> public SoapFaultPortType getSoapFaultPortType(WebServiceFeature... features) {
> return super.getPort(new QName("http://jbossts.jboss.org/xts/soapfault", "SoapFaultPortType"), SoapFaultPortType.class, features);
> }
> }
>
> @WebService(name = "SoapFaultPortType", targetNamespace = "http://jbossts.jboss.org/xts/soapfault")
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
> @XmlSeeAlso({
> ObjectFactory.class
> })
> public interface SoapFaultPortType {
> /**
> *
> * @param fault
> */
> @WebMethod(operationName = "SoapFault")
> @Oneway
> public void soapFault(
> @WebParam(name = "Fault", targetNamespace = "http://schemas.xmlsoap.org/soap/envelope/", partName = "fault")
> Fault fault);
> }
The problem is that when my tests try to create a SoapFaultPortType I get a parse error during processing of the WSDL. Unfortunately, the error is not reported as being in my WDSL. It ahppens wen processing the imported schema
> <s:schema>
> <s:import namespace=" http://schemas.xmlsoap.org/soap/envelope/ http://schemas.xmlsoap.org/soap/envelope/"
> schemaLocation=" http://schemas.xmlsoap.org/soap/envelope http://schemas.xmlsoap.org/soap/envelope"/>
> </s:schema>
I stepped through the code and found that it successfully loads the schema located at http://schemas.xmlsoap.org/soap/envelope http://schemas.xmlsoap.org/soap/envelope but then runs into problems processing the contents. Here is the error message:
> [Fatal Error] strict.dtd:81:5: The declaration for the entity "ContentType" must end with '>'.
> [Fatal Error] envelope:2:2: The markup in the document following the root element must be well-formed.
> javax.xml.ws.WebServiceException: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:152)
> at org.apache.cxf.jaxws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:63)
> at javax.xml.ws.Service.<init>(Service.java:57)
> at org.jboss.jbossts.xts.soapfault.SoapFaultService.<init>(SoapFaultService.java:46)
> at com.arjuna.webservices11.wsaddr.client.SoapFaultClient.getSoapFaultService(SoapFaultClient.java:98)
> at com.arjuna.webservices11.wsaddr.client.SoapFaultClient.getSoapFaultPort(SoapFaultClient.java:130)
> at com.arjuna.webservices11.wsaddr.client.SoapFaultClient.sendSoapFault(SoapFaultClient.java:86)
> at com.arjuna.webservices11.wsat.client.CompletionInitiatorClient.sendSoapFault(CompletionInitiatorClient.java:123)
> at com.arjuna.wst11.tests.junit.CompletionCoordinatorTestCase.testSendError(CompletionCoordinatorTestCase.java:180)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:24)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:117)
> at com.arjuna.qa.junit.TestRunnerServlet$RunnerThread.run(TestRunnerServlet.java:523)
> Caused by: org.apache.cxf.service.factory.ServiceConstructionException: Failed to create service.
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:93)
> at org.apache.cxf.jaxws.ServiceImpl.initializePorts(ServiceImpl.java:207)
> at org.apache.cxf.jaxws.ServiceImpl.<init>(ServiceImpl.java:150)
> ... 46 more
> Caused by: javax.wsdl.WSDLException: WSDLException (at /definitions/types/s:schema): faultCode=PARSER_ERROR: Problem parsing 'http://schemas.xmlsoap.org/soap/envelope'.: org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
> at com.ibm.wsdl.xml.WSDLReaderImpl.getDocument(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseSchema(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseTypes(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.parseDefinitions(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at com.ibm.wsdl.xml.WSDLReaderImpl.readWSDL(Unknown Source)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.loadDefinition(WSDLManagerImpl.java:230)
> at org.apache.cxf.wsdl11.WSDLManagerImpl.getDefinition(WSDLManagerImpl.java:179)
> at org.apache.cxf.wsdl11.WSDLServiceFactory.<init>(WSDLServiceFactory.java:91)
> ... 48 more
> Caused by: org.xml.sax.SAXParseException: The markup in the document following the root element must be well-formed.
> at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
> at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
> ... 58 more
>
As you can see the problem occurs under ServiceImple.<init> below SoapFaultService.<init> when trying to create the SoapFaultService class generated by wsconsume. This is somewhat bizarre given where the schema comes from.
Ok, so you might want an explanationfor what this servcie is and why it needs to import the soap envelope schema. It's abit copnvoluted but here goes. XTS implements the WS-C and WS-T services defined by the WSTX standard. WS-C includes two generic services for creating and enlisting with transactions from various transaction transaction protocols. WS-T includes two families of transaction protocol specific services which allow transaction clients and transactional web services to progress towards completion completion. The service APIs are specified by WSDL and our rimplementation uses JaxWS to implement that WSDL.
The WS-T services (WS-AT atomic transaction and WS-BA business activity), are only mandated only to employ a OneWay MEP. Tthe SOAP used to deliver these messages is required to be configured with various mandatory WSA headers, including MessageId, ReplyTo and FaultTo. The SOAP headers also need to include service specific transaction identifiers as header elements. This is achieved by by installing them as ReferenceParameters in the endpoints used by the transaction protocol services and transactional web services communicate ie. they are attached to
* the transaction protocol specific Coordinator service endpoints handed out to transactional web services by the WS-C registration service when they enlist in a transaction
* the endpoint in the ReplyTo/FaultTo header included by web services when they negotiate with the registration service or with their Coordinator service
Yes, as you can see, the use of one way messaging means that the container for the transactional web service must also contain a WS-AT or WS-BA Initiator service. The Coordinator talks back to this Initiator service in order to be able to constuct a long-running dialogue with the transactional web service composed of a series of 1-way messages such as e.g. +enlist+, +prepare+, +prepared+, +commit+, +commited+. In the case of WS-BA this dialogue can be initiated asynchronously from either end -- that's why OneWay MEP was chosen over RPC.
The service specification mandates that in cases where processing of a message runs into certain error conditions a SoapFault must be dispatched to the FaultTo addess configured in the WSA headers. Obviously, if a fault occurs in +delivering+ the message the JaxWS layer will dispatch a fault to the sender. But that's not that the spec is talking about (or at least not +all+ it is talking about). The spec is concerned with faults which occur after delivery when the delivered message is being processed. By this stage JaxWS has done its stuff and told the sender 'message delivered'. If the service endpoint bean were to throw a fault nothing would get dispatched back to the sender. So, the threads which are handling a request to the Coordinator or Initiator services need to be able to dispatch a fault to the FaultTo address asynchronously -- from a standing start. This fault needs to
* be sent to the FaultTo address
* provide a WSA RelatesTo header whcih includes the originating MessageId
* include the ReferenceParameter header obtained with the FaultTo address.
Now the WS-AT/BA coordinator and initiator service enpoint implementation classes all implement a WebMethod which accepts a SoapFault with a specific SOAPAction or WSA Action. This web method is declared by interface SoapFaultPortType generated from the SoapFaultService WSDL and all these services implement the interface i.e.they are capable of acting as an endpoint for the SoapFaultPortType of the SoapFaultService. Now, in order to dispatch an asynchronous SoapFault to the sender the handler thread merely needs to create a fault and an instance of SoapFaultService then clone a proxy port from it and call method soapFault(). So this is what is happening when my current implementation blows up trying to read the soap envelope WSDL.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548690#548690]
Start a new discussion in JBoss Web Services CXF at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months
[jBPM] - Multiple JBPM4_VARIABLE records pointing to same LOB_ and different EXECUTIONID_
by Jorge Ferreira
Jorge Ferreira [http://community.jboss.org/people/imjorge] created the discussion
"Multiple JBPM4_VARIABLE records pointing to same LOB_ and different EXECUTIONID_"
To view the discussion, visit: http://community.jboss.org/message/548684#548684
--------------------------------------------------------------
I am using jBPM 4.3. If you need any more version information please ask.
We get an exception when trying to call ExecutionService#endProcessInstance(...).
org.zkoss.zk.ui.UiException: rendering.0010: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.lob.Lob#2260042].
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.zkoss.lang.Classes.newInstance(Classes.java:76)
at org.zkoss.lang.Exceptions.wrap(Exceptions.java:162)
at org.zkoss.zk.ui.UiException$Aide.wrap(UiException.java:44)
at org.zkoss.zk.ui.impl.UiEngineImpl.processEvent(UiEngineImpl.java:1452)
at org.zkoss.zk.ui.impl.UiEngineImpl.process(UiEngineImpl.java:1229)
at org.zkoss.zk.ui.impl.UiEngineImpl.execUpdate(UiEngineImpl.java:1009)
at org.zkoss.zk.au.http.DHtmlUpdateServlet.process(DHtmlUpdateServlet.java:549)
at org.zkoss.zk.au.http.DHtmlUpdateServlet.doGet(DHtmlUpdateServlet.java:441)
at org.zkoss.zk.au.http.DHtmlUpdateServlet.doPost(DHtmlUpdateServlet.java:449)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:182)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
at java.lang.Thread.run(Thread.java:619)
Caused by: rendering.0010: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.lob.Lob#2260042].
at com.csw.impression.rendering.component.action.OutcomeAction.execute(OutcomeAction.java:177)
at com.csw.impression.rendering.component.action.event.ExecuteActionEventListener.onEvent(ExecuteActionEventListener.java:49)
at org.zkoss.zk.ui.impl.EventProcessor.process0(EventProcessor.java:196)
at org.zkoss.zk.ui.impl.EventProcessor.process(EventProcessor.java:140)
at org.zkoss.zk.ui.impl.UiEngineImpl.processEvent(UiEngineImpl.java:1445)
... 26 more
Caused by: javax.ejb.EJBException: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.lob.Lob#2260042]
at org.jboss.ejb3.tx.Ejb3TxPolicy.handleExceptionInOurTx(Ejb3TxPolicy.java:63)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:83)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:83)
at org.jboss.ejb3.security.RunAsSecurityInterceptor.invoke(RunAsSecurityInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:166)
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:115)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:240)
at org.jboss.ejb3.stateless.StatelessContainer.localInvoke(StatelessContainer.java:210)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:84)
at $Proxy248.completeTask(Unknown Source)
at com.csw.impression.rendering.component.panel.AbstractPanel.executeOutcome(AbstractPanel.java:686)
at com.csw.impression.rendering.component.action.OutcomeAction.execute(OutcomeAction.java:129)
... 30 more
Caused by: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.lob.Lob#2260042]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2541)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2697)
at org.hibernate.action.EntityDeleteAction.execute(EntityDeleteAction.java:74)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:146)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.jbpm.pvm.internal.tx.HibernateSessionResource.prepare(HibernateSessionResource.java:56)
at org.jbpm.pvm.internal.tx.StandardTransaction.commit(StandardTransaction.java:107)
at org.jbpm.pvm.internal.tx.StandardTransaction.complete(StandardTransaction.java:64)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:61)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.svc.TaskServiceImpl.completeTask(TaskServiceImpl.java:96)
at com.csw.impression.bpm.ExecutionServiceImpl.completeTaskWork(ExecutionServiceImpl.java:206)
at com.csw.impression.bpm.ExecutionServiceImpl.completeTask(ExecutionServiceImpl.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.aop.joinpoint.MethodInvocation.invokeTarget(MethodInvocation.java:122)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:111)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
... 55 more
Caused by: java.sql.SQLException: The DELETE statement conflicted with the REFERENCE constraint "FK_VAR_LOB". The conflict occurred in database "impression", table "dbo.JBPM4_VARIABLE", column 'LOB_'.
at net.sourceforge.jtds.jdbc.SQLDiagnostic.addDiagnostic(SQLDiagnostic.java:368)
at net.sourceforge.jtds.jdbc.TdsCore.tdsErrorToken(TdsCore.java:2820)
at net.sourceforge.jtds.jdbc.TdsCore.nextToken(TdsCore.java:2258)
at net.sourceforge.jtds.jdbc.TdsCore.getMoreResults(TdsCore.java:632)
at net.sourceforge.jtds.jdbc.JtdsStatement.processResults(JtdsStatement.java:584)
at net.sourceforge.jtds.jdbc.JtdsStatement.executeSQL(JtdsStatement.java:546)
at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.executeUpdate(JtdsPreparedStatement.java:506)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
at org.hibernate.persister.entity.AbstractEntityPersister.delete(AbstractEntityPersister.java:2523)
... 88 more
FK_VAR_LOB is a foreign key constraint for JBPM4_VARIABLE.LOB_ column that points to JBPM4_LOB.DBID_. This error means that a DELETE for a record in JBPM4_LOB conflicts with a record in JBPM4_VARIABLE that points to that same record.
I think this problem is related with this strange situation.
The LOB_ in question is 2260042 (see next line).
org.zkoss.zk.ui.UiException: rendering.0010: org.hibernate.exception.ConstraintViolationException: could not delete: [org.jbpm.pvm.internal.lob.Lob#2260042].
So I did a query on JBPM4_VARIABLE for any records with that LOB_.
*select * from jbpm4_variable where lob_ is not null and lob_ = 2260229*
And I got two records that:
* use *ser-bytes* converter;
* have two diferent *KEY_* names;
* have two different *EXECUTIONID_* values;
* Point to the same *LOB_*.
Oddly enough the *EXECUTIONID_* values are for different processes.
*select dbid_, procdefid_ from jbpm4_execution where dbid_ in (2260197, 2260223)*
For setting a variable value we always use several API, but all from publicly exposed jBPM interfaces:
* OpenExecution.setVariable(...);
* ActivityExecution.setVariable(...);
* ExecutionService.setVariable(...);
So, to make my questions clear.
Is this behavior normal for JBPM4_VARIABLE, I would have guessed it is not?
And, what could be causing this strange behavior?
Feel free to ask any more input, data that you consider could help investigating further this issue.
-- Jorge
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/548684#548684]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 10 months