Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: 
 <CADmm+KcE8TpDq=Vs-Aku-y22XQGYHxmW5gkkO-KYsXCi7683Vg@mail.gmail.com>
References: 
 <CADmm+KcE8TpDq=Vs-Aku-y22XQGYHxmW5gkkO-KYsXCi7683Vg@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Wed, 24 Jun 2015 23:40:37 +0800
Message-ID: 
 <CADmm+KcA6YdpqPFw5EiHQz+6yCunCp35OSve7p069kkQT-+PWw@mail.gmail.com>
Subject: Re: Bug found in UnitOfWork
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2fd9e33adfa05194555c4

--001a11c2fd9e33adfa05194555c4
Content-Type: text/plain; charset=UTF-8

Follow-up; The case when it gets wrong is more complex than my list, and I
am not able to create a testcase for this...

On Wed, Jun 24, 2015 at 10:51 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> Gang,
>
> I have found a fairly sophisticated bug, which is rather severe and
> possibly hard to fix without breaking applications, that might depend on
> wrong behavior...
>
> It manifests itself as not having the right Visibility of entities, and
> the reason is because the EntityStoreUnitOfWork may be set up incorrectly
> sometimes.
>
> I think it happens if the following sequence occurs;
>
>  a. Creation of a UnitOfWork
>  b. Accessing entity E in module M
>  c. Entity E calls service S in module N.
>  d. Service S tries to access entity F in module N.
>
> internally, the EntityStoreUnitOfWork will have been initialized with the
> Module M, and uses that to find entity F, which is not seen
> (Visibility.module).
>
> This is very similar to a design flaw a long time ago, where the
> visibility was effectively in the wrong Layer, and that is when the "split"
> UnitOfWork concept was introduced (2008?).
>
> The issue manifests itself in UnitOfWorkInstance in the following method;
>
> public EntityStoreUnitOfWork getEntityStoreUnitOfWork( EntityStore store, Module module )
> {
>     EntityStoreUnitOfWork uow = storeUnitOfWork.get( store );
>     if( uow == null )
>     {
>         uow = store.newUnitOfWork( usecase, module, currentTime );
>         storeUnitOfWork.put( store, uow );
>     }
>     return uow;
> }
>
> as the EntityStoreUnitOfWork will have been created with the wrong module.
>
> I think the solution is that the Module must also be part of the cache
> key, and that this would solve it. However, I am very anxious that this may
> break something else very badly, as it is fairly central to the entire
> UnitOfWork flow.
>
> The reason I say that it might break applications is that, the called
> Service has access to the entities in the modules calling it, and someone
> might depend on that. But I think, we should be allowed to break bug
> compatibility... Or??
>
> BTW, this touches on the "multiple entitystore" feature that came up
> during the discussion of the Messaging abstraction.
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--001a11c2fd9e33adfa05194555c4--