[ https://issues.jboss.org/browse/DROOLS-1541?page=com.atlassian.jira.plugi... ] Matteo Mortari edited comment on DROOLS-1541 at 5/9/17 8:22 AM: ---------------------------------------------------------------- I don't believe there is an error in the documentation, neither there is an error in the code. I believe the real problem here is mixing two api approaches, using the Commands Vs calling operations directly on the KieSession. Therefore, if one had to use only the Commands API, none of the mentioned issue would manifest. Anyway, given the Commands API does not support the case of calling "update" and replacing the actual object instance, there could be an edge-case of mixing the two approaches. But even in the case of mixing Commands API and calling operations directly on the KieSession, it is (still) *incorrect* to reuse a ExecutionResults after subsequent operations have been performed directly on the KieSession. This is because ExecutionResults represents a "snapshot" of the results of the execution of the Commands, contextually to the KieSession.execute(Command c). Once the execute returns a given ExecutionResults instance, the KieSession does NOT keep a reference to it, and that given instance will not be updated following subsequent KieSession API call. If the user want an updated ExecutionResults, it will require a new execute of Commands, which will return a consistent (new, up-to-date) ExecutionResults instance. I want to stress the fact the ExecutionResults represent the result contextually to the Commands API call. As an example see below, although I would NOT recommend it as it mixes Commands API and calling operations directly on the KieSession. {code:java} // Step1 ExecutionResults resultsA = session.execute( CommandFactory.newBatchExecution( Arrays.asList(new Command[]{ CommandFactory.newInsert( new Measurement("color", "red"), "my_out_ID" ), CommandFactory.newFireAllRules() })) ); FactHandle redFH = (FactHandle) resultsA.getFactHandle("my_out_ID"); // Step2 Object replacedInstance = new Measurement("color", "reddish"); session.update(redFH, replacedInstance ); session.fireAllRules(); // Step3 ExecutionResults resultsB = session.execute( CommandFactory.newBatchExecution( Arrays.asList(new Command[]{ CommandFactory.newGetObject(redFH, "my_out_ID") })) ); assertEquals( replacedInstance, resultsB.getValue("my_out_ID") ); {code} At step2, it would be INCORRECT to re-use the ExecutionResults coming from step1. The more correct approach in this case would be to retrieve an up-to-date ExecutionResults instance by calling a new execute Commands, i.e.: step3, notice the final assert statement I hope this clarifies the misunderstanding. If I incorrectly interpreted your original description, kindly let us know, please (eventually re-opening this jira) Thank you, MM was (Author: tari_manga): I don't believe there is an error in the documentation, neither there is an error in the code. I believe the real problem here is mixing two api approaches, using the Commands Vs calling operations directly on the KieSession. Therefore, if one had to use only the Commands API, none of the mentioned issue would manifest. Anyway, given the Commands API does not support the case of calling "update" and replacing the actual object instance, there could be an edge-case of mixing the two approaches. But even in the case of mixing Commands API and calling operations directly on the KieSession, it is (still) *incorrect* to reuse a ExecutionResults after subsequent operations have been performed directly on the KieSession. This is because ExecutionResults represents a "snapshot" of the results of the execution of the Commands, contextually to the KieSession.execute(Command c). Once the execute returns a given ExecutionResults instance, the KieSession does NOT keep a reference to it, and that given instance will not be updated following subsequent KieSession API call. If the user want an updated ExecutionResults, it will require a new execute of Commands, which will return a consistent (new, up-to-date) ExecutionResults instance. I want to stress the fact the ExecutionResults represent the result contextually to the Commands API call. As an example see below, although I would NOT recommend it as it mixes Commands API and calling operations directly on the KieSession. {code:java} // Step1 ExecutionResults resultsA = session.execute( CommandFactory.newBatchExecution( Arrays.asList(new Command[]{ CommandFactory.newInsert( new Measurement("color", "red"), "my_out_ID" ), CommandFactory.newFireAllRules() })) ); FactHandle redFH = (FactHandle) resultsA.getFactHandle("my_out_ID"); // Step2 Object replacedInstance = new Measurement("color", "reddish"); session.update(redFH, replacedInstance ); session.fireAllRules(); // Step3 ExecutionResults resultsB = session.execute( CommandFactory.newBatchExecution( Arrays.asList(new Command[]{ CommandFactory.newGetObject(redFH, "my_out_ID") })) ); assertEquals( replacedInstance, resultsB.getValue("my_out_ID") ); {code} At step2, it would be INCORRECT to re-use the ExecutionResults coming from step1. The more correct approach in this case would be to retrieve an up-to-date ExecutionResults instance by calling a new execute Commands, i.e.: step3. I hope this clarifies the misunderstanding. If I incorrectly interpreted your original description, kindly let us know, please (eventually re-opening this jira) Thank you, MM -- This message was sent by Atlassian JIRA (v7.2.3#72005)