Hi Igor, ok, have managed to track down the issue... it wasn't with the child command being persisted, rather DN's persistence-by-reachability was trying to persist the incomplete "parent" command. I think the solution is simply to not attempt to associate the new background command with any parent command (there is no "user intent").
I'll put out a release this evening. Thx Dan On 14 April 2016 at 21:02, Dan Haywood <[email protected]> wrote: > Ah, ok. > Apologies that I didn't look at the test case that you kindly put together > ; I right I had deduced the issue from rereading your email. > I shall look into it once more! > Thx, Dan. > On 14 Apr 2016 20:53, "Igor Lobanov" <[email protected]> > wrote: > >> Dan, >> Thanks for looking into this. Apologies for not responding promptly, >> somehow I managed to miss your response. I do use >> BackgroundCommandExecutionFromBackgroundCommandServiceJdo in my Quartz job >> to run background commands, but the problem arises before that class gets >> into the picture, i.e. during the time when CommandJdo is being flushed >> into the database, which happens in an ordinary Quartz job without any >> command context. The test app which I have uploaded simlulates this using a >> simple background thread. >> -- Best regards, Igor Lobanov >> >> On Monday, 11 April 2016, 20:28, Dan Haywood < >> [email protected]> wrote: >> >> >> >> Hi Igor, >> just looking into this now and reminding myself of what the design was... >> >> ... did you look into using BackgroundCommandExecution, rather than >> AbstractIsisSessionTemplate (of which it is a subclass?) This will >> initialize the parent command for you, I think. >> >> The BackgroundCommandExecutionFromBackgroundCommandServiceJdo in turn is a >> concrete implementation which you could have Quartz call every 30 seconds >> or so. There's actually an example QuartzJob at [1] >> >> HTH >> Dan >> >> >> [1] >> >> https://isis.apache.org/guides/rgsvc.html#_rgsvc_api_BackgroundService_BackgroundCommandExecution >> >> >> >> >> On 9 April 2016 at 18:46, Dan Haywood <[email protected]> >> wrote: >> >> > Thanks Igor, >> > >> > I'll do my best to take a look tomorrow. >> > >> > Dan >> > >> > >> > On 9 April 2016 at 18:45, Igor Lobanov <[email protected]> wrote: >> > >> >> I've created simple project demonstrating the behaviour: >> >> https://github.com/lobanov/apache-isis-bug1 >> >> >> >> README.md provides a sequence of steps required to reproduce the >> >> behaviour, hopefully it is clear enough. >> >> >> >> -- Best regards, Igor Lobanov >> >> >> >> >> >> On Saturday, 9 April 2016, 16:21, Dan Haywood < >> >> [email protected]> wrote: >> >> >> >> >> >> >> >> Just use the simpleapp archetype and add in the minimal amount of stuff >> >> needed to demonstrate the issue. >> >> Thx, >> >> Dan >> >> On 9 Apr 2016 16:05, "Igor Lobanov" <[email protected]> >> >> wrote: >> >> >> >> Sure, although I need an advice on how to best approach it. Is there an >> >> easy way of bootstrapping Isis as a standalone app using HSQL or >> something >> >> similar? >> >> -- Best regards, Igor Lobanov >> >> >> >> On Saturday, 9 April 2016, 15:33, Dan Haywood < >> >> [email protected]> wrote: >> >> >> >> >> >> >> >> That does sound like an issue. Probably the issue is in the addons >> >> implementation rather than in Isis "proper", so will a bit easier to >> >> release a fix if that is a problem. >> >> >> >> Could you put together a simple example on github that demonstrates the >> >> problem, and document on its README how to reproduce? >> >> >> >> Thx, >> >> Dan. >> >> On 9 Apr 2016 15:28, "Igor Lobanov" <[email protected]> >> >> wrote: >> >> >> >> All, >> >> I am running business logic in background using Quartz. To that end I >> am >> >> extending AbstractIsisSessionTemplate in my job classes and overriding >> >> doExecuteWithTransaction() to do something useful, so far so good. Now >> I >> >> need to schedule some actions to be executed in the background outside >> the >> >> main scheduled job. This is because spawned tasks themselves may fail, >> but >> >> it must not cause the main job to fail as well. >> >> The project makes use of isis-module-command addon to schedule >> background >> >> commands from the UI, so I went on and wrote a logic that calls >> >> BackgroundService#execute(...) in the job code. Apparently this doesn't >> >> work, as I'm getting a few 'cannot insert null into non-null column' >> when >> >> CommandJdo INSERTs are being flushed. It is difficult for me to work >> out >> >> what the problem is by reading the code, but it seems that >> >> BackgroundService#execute(...) assumes invocation from the context of >> >> another parent command, which apparently is not so when the code is >> >> running >> >> in a background thread. >> >> >> >> Ideally, I want to make use of BackgroundService#execute(...) rather >> than >> >> building something custom. Is there a particular way to invoke it from >> a >> >> background thread aside from >> >> AbstractIsisSessionTemplate#doExecuteWithTransaction()? Do I need to >> >> 'spoof' a parent command somehow? I would appreciate any suggestion. >> >> -- Best regards, Igor Lobanov >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >
