isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Xiao <michael.b.x...@gmail.com>
Subject Re: Regards to Audit Service
Date Sun, 02 Feb 2014 20:01:25 GMT
Thanks Dan,

Will try uploading the code somewhere and let you know.

Regards,
Michael


On 2 February 2014 21:40, Dan Haywood <dan@haywood-associates.co.uk> wrote:

> On 2 February 2014 01:58, Michael Xiao <michael.b.xiao@gmail.com> wrote:
>
> > 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 think you are on the latest... 1.3.1 was only an update to the wicket
> viewer. [1]
>
> >
> > 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.
> >
> >
> It does sound like a possible reason, but it's a bid hard to say without
> seeing all the code and how the master thread (that sounds like it is
> co-ordinating the work/doing auditing) and child threads (that generate
> stuff) interact.
>
> In Isis (as I'm sure you've figured out), each transaction is scoped by
> thread by installing IsisContextThreadLocal as the implementation of
> IsisContext.  I'm presuming that each child thread uses its own
> IsisContext?  But if instead it's the master thread that creates an
> IsisContext and then hands it off to the child threads, then I'm not sure
> what would happen.
>
> So I guess what I'm asking is:
> a) how does the master thread know that the child thread has finished? and
> b) how do the two threads share information (the changedObjectProperties
> map)?
>
> Can you upload the relevant code somewhere so I can take a look?
>
> Cheers
> Dan
>
>
>
> > 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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message