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.213.172 as permitted sender)
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: <558B24B6.7070604@gmail.com>
References: 
 <CADmm+KcE8TpDq=Vs-Aku-y22XQGYHxmW5gkkO-KYsXCi7683Vg@mail.gmail.com>
 <CADmm+KcA6YdpqPFw5EiHQz+6yCunCp35OSve7p069kkQT-+PWw@mail.gmail.com>
 <558B24B6.7070604@gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Thu, 25 Jun 2015 14:44:22 +0800
Message-ID: 
 <CADmm+KfsKdUt80s+uj1HV_mzxR-4to5jLW9favT5k+nOby-ykQ@mail.gmail.com>
Subject: Re: Bug found in UnitOfWork
To: dev <dev@zest.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2fd9e4e0025051951f5a1

--001a11c2fd9e4e0025051951f5a1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Yes, you are right, the cache key can't be done as I suggested.

Further, I have looked into why there is a Module assigned into the
EntityStoreUnitOfWork, and it boils down to, as usual, to the
deserialization of entities. It basically needs to know where to look for
the entity types.

And that is quite interesting; Is it simply a matter of bad design, i.e.
violation of the Aggregate concept of DDD?

So, analyzing my particular case; Yes, I would say so.

What I am doing is using the Scheduling Library, and upon creating certain
entities, it also creates a schedule to callback to those entities every 5
minutes. So, my fault is that this is inlined in the normal entity
creation, but should actually be a SideEffect on a new UnitOfWork.

So, is that always the case? Is it simply that one needs to think harder
about the design choices and not do these things? There is obviously a lot
of other cases where it works more like expected, since I have problem to
re-implement the issue in a testcase.

Niclas

On Thu, Jun 25, 2015 at 5:44 AM, Kent S=C3=B8lvsten <kent.soelvsten@gmail.c=
om>
wrote:

> Hmmm interesting problem . Could it be reproduced with something like thi=
s:
>
> a. Creation of a UnitOfWork
> b. Accessing entity M1 in module M
> c. Entity E calls service MS in module M.
> d. Service uses entity N1 in module N (N1 has some sort of shared
> visibility)
> .... (later in the same UOW)
> e. Someone uses service NS in module N (some short of shared visibility).
> f. Service NS uses entity N2 in module N (which has only module visibilit=
y)
>
> I am not sure that using a composite module/entitystore cache key is
> such a good idea. Wouldn't that lead to 2 instances of
> EntityStoreUnitOfWork, basically splitting uow.complete() into 2 native
> transactions in that case?
> Could we instead reuse the "ModuleUnitOfWork-idea" ?
>
> Something like:
>
>     public EntityStoreUnitOfWork getEntityStoreUnitOfWork( EntityStore
> store, Module module )
>
>     {
>
>         EntityStoreUnitOfWork uow =3D storeUnitOfWork.get( store );
>
>         if( uow =3D=3D null )
>
>         {
>
>             uow =3D store.newUnitOfWork( usecase, currentTime );    // no
> module here!
>
>             storeUnitOfWork.put( store, uow );
>
>         }
>
>         return new ModuleEntityStoreUnitOfWork(uow, module);
>
>     }
>
> As a side-note we could one day consider some sort of
> entitystore-sharing between modules. If we had 2 modules, separated for
> design reasons but sharing the same persistence, it would be nice to be
> able to complete a UOW spanning those 2 modules in a single native
> transaction.
>
> Regarding "bug-compatible" the safe option would be to postpone to 3.0 -
> but i guess it is better to just fix the issue?
>
> /Kent
>
>
>
> Den 24-06-2015 kl. 17:40 skrev Niclas Hedhman:
> > Follow-up; The case when it gets wrong is more complex than my list, an=
d
> 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, an=
d
> >> 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 =3D storeUnitOfWork.get( store );
> >>     if( uow =3D=3D null )
> >>     {
> >>         uow =3D 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 thi=
s
> 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
> >>
> >
> >
>
>


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

--001a11c2fd9e4e0025051951f5a1--