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 > >> > >> > >> > >> > >> > >> > >> > >> > > > > > >
