isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <>
Subject Re: Regards to Audit Service
Date Sun, 02 Feb 2014 08:40:07 GMT
On 2 February 2014 01:58, Michael Xiao <> 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

Can you upload the relevant code somewhere so I can take a look?


> 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

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