Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
Received-SPF: pass (nike.apache.org: domain of hedhman@gmail.com designates
 209.85.223.175 as permitted sender)
MIME-Version: 1.0
Sender: hedhman@gmail.com
From: Niclas Hedhman <niclas@hedhman.org>
Date: Wed, 24 Jun 2015 22:51:18 +0800
Message-ID: 
 <CADmm+KcE8TpDq=Vs-Aku-y22XQGYHxmW5gkkO-KYsXCi7683Vg@mail.gmail.com>
Subject: Bug found in UnitOfWork
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a1135f1a6d800ab051944a4cf

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

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

--001a1135f1a6d800ab051944a4cf--