polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Bug found in UnitOfWork
Date Wed, 24 Jun 2015 14:51:18 GMT

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

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

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.

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

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