polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Bug found in UnitOfWork
Date Thu, 25 Jun 2015 11:23:19 GMT
Kent,
I tried to implement the ModuleEntityStoreUnitOfWork idea. It is not as
smooth as it first seems, since the inner EntityStoreUnitOfWork needs to
call entityStateOf() which needs the module. BUT, by modifying a couple of
SPI interfaces, it is possible to pass the Module along in method calls.
Along with removing EntityStoreUnitOfWork in some cases where only
something inside the EsUoW is actually wanted, which in some cases resulted
in creating a EsUoW for no practical reason, I have it working.... i.e.
doesn't break any existing testcases. I haven't checked whether my case was
solved as well. Will do that shortly.



On Thu, Jun 25, 2015 at 5:44 AM, Kent SĂžlvsten <kent.soelvsten@gmail.com>
wrote:

> Hmmm interesting problem . Could it be reproduced with something like this:
>
> 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 visibility)
>
> 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 = storeUnitOfWork.get( store );
>
>         if( uow == null )
>
>         {
>
>             uow = 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, 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

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