Mailing-List: contact users-help@isis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@isis.apache.org
Received-SPF: pass (nike.apache.org: domain of michael.b.xiao@gmail.com
 designates 209.85.128.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALJOYLEJCNCg34Qpt=mN_-OOW8AcVv8_57ssMjd-iaauPQweVw@mail.gmail.com>
References: 
 <CADc5G+YJbpFqacRF+7FxDMd2UqOo+z9R0-anyfvwcVfMFVLvXQ@mail.gmail.com>
	<CADc5G+YbnXg0ALNjgS5bTwu8tN_gb2ePzYq4KNqL2rEPzh-Fgg@mail.gmail.com>
	<CALJOYLEJCNCg34Qpt=mN_-OOW8AcVv8_57ssMjd-iaauPQweVw@mail.gmail.com>
Date: Sun, 2 Feb 2014 14:58:27 +1300
Message-ID: 
 <CADc5G+YgDdxrw0-DFaqthJQ=jLSRpHmdAMpd0XX-EZP3Zq-yHA@mail.gmail.com>
Subject: Re: Regards to Audit Service
From: Michael Xiao <michael.b.xiao@gmail.com>
To: users@isis.apache.org
Content-Type: multipart/alternative; boundary=047d7b5d2dc63fef9804f162beeb

--047d7b5d2dc63fef9804f162beeb
Content-Type: text/plain; charset=ISO-8859-1

Hi Dan,

Thanks very much for your reply.

We are using Isis 1.3.0 (with the 1.3.1 wicket viewer). Hmm.... may be
worth trying the latest 1.3.1 and see if solves the problem.

I did a bit more testing today; I suspect it MIGHT be an issue related to
multi-threading. As said, the *enlistCreated *method was only invoked by
the FrameworkSynchronizer which updates the value of property
changedObjectProperties in a *new thread*. Upon the committing of the
transaction,  the master thread (the batch job thread) reads the property,
and creates audit entries based on it. In case if the master thread
finishes earlier than the thread updating the changedObjectProperties, the
program may pick up a partially completed list/map. However, this is just
my understanding. Might be wrong. :0) Any thoughts? Thanks in advance.


IsisTransaction
==============================================================
public void enlistUpdating(ObjectAdapter adapter)
 {
   enlist(adapter, PublishedObject.ChangeKind.UPDATE);

   for (ObjectAssociation property :
adapter.getSpecification().getAssociations(Contributed.EXCLUDED,
ObjectAssociation.Filters.PROPERTIES)) {
      AdapterAndProperty aap = AdapterAndProperty.of(adapter, property);
      if (property.isNotPersisted()) {
          continue;
      }

     PreAndPostValues papv = PreAndPostValues.pre(aap.getPropertyValue());
     this.*changedObjectProperties*.put(aap, papv);
   }
 }


Regards,
Michael


On 31 January 2014 22:23, Dan Haywood <dan@haywood-associates.co.uk> wrote:

> On 31 January 2014 01:34, Michael Xiao <michael.b.xiao@gmail.com> 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
> >
>

--047d7b5d2dc63fef9804f162beeb--