On 31 January 2014 01:34, Michael Xiao <[email protected]> wrote:
> Hello Dan, > > This is my first email after using the Isis for more than a year. I've been > working with David Tildesley and we both loved the framework. Thank you for > the great work!!! > You're welcome, glad you've enjoyed using the framework. I know from David that it's a commercial system so there's limits on what you can say, but it'd be great to have a little write-up of your app/system/product for the Isis website. It's only through that sort of material will the community grow faster. > > David has urged me to drop you an email to discuss an "issue" we found > yesterday, which may relate to the audit function :0) > [snip] > > All entities including their relationships had been persisted correctly. > However, the auditing for employment position assignment change, was not > always triggered and persisted. > > I've done a few tests around this. What I've noticed is that if I run this > task in (Eclipse) debug mode, and add a break-point in > IsisTransaction.enlistUpdating method, the audit entry can be saved without > any problem. However, if running this without any pause, there is no > guarantee the audit entry will be logged. > > Not sure what actually caused this. Wonder if you guys have encountered > this before. Can you please advise? > > Hmm, tricky one... don't have a magic bullet for you, I'm afraid. I have some a couple of ideas, though. How enlistUpdating works is that we are relying upon DataNucleus to do a callback to Isis when an entity is dirtied by it. If - while in the debugger - you look at the callstack you should see a call through FrameworkSynchronizer class - this (and also IsisLifeCycleListener which delegates to it) is where Isis gets notified by DN that an entity has changed. My best guess is that the act of being in the debugger (and inspecting variables etc) is causing an additional resolve/load of an object to fire... a sort of Schrodinger's cat affair. To track this down, all I can think of is to run the same commands with logging, once in the debugger (when it works) and once outside the debugger (when it sometimes doesn't) and see how the log files vary. You could, then, perhaps force a resolve of the missed entity in your domain code. The IsisJdoSupport service has some methods that might help. A work-around, I know, but perhaps necessary to help us understand what's going on. ~~~ My only other thought was whether this was due to a threading issue (though I very much doubt it)? We can easily rule it out... does this only occur in a multi-user environment, or can you replicate just by running your batch job as a single task. ~~~ If you could put together a simple example on github showing the issue, I'll gladly take a look. Can you also confirm which version of Isis are you running on - is it the latest 1.3.1, or are you (even) working off trunk? Thx Dan PS: I'm just working on enhancements to audit service and new related services. I don't think they will fix this issue, but the API of AuditingService is changing a little bit... a ten minute refactoring job if you have your own implementation. More details to follow. > Many thanks in advance. > > Best Regards, > > > Michael >
