BaseEntity optimistic locking
Marcin Kuthan
If you use timestamp version locking you need to be very careful of your milliseconds precision. Ensure your database supports milliseconds precisely otherwise you may have issues, especially if the value is assigned in Java, then differs what gets stored on the database, which will cause the next update to fail for the same object.
In general I would not recommend using a timestamp and as primary key or for version locking. There are too many database compatibility issues, as well as the obvious issue of not supporting two operations in the same millisecond.
Sławomir Sobótka
> entities are the good candidates for opt locking (but perhaps also not
> always). Aggregate entity is an entry point, so it can be responsible for
> locking also.
In general BaseEntity and BaseAggregate are pulled just in sake of
comfort. But still in respect of Liskov SP.
Someone using Leaven can always introduce as many base classes (in any
hierarchy) as it makes sense for him.
So if locking is not needed, than it can be easily moved/removed. This
is just a sample of technique.
You are right that if Aggregate is a Unit of Change than it can be
responsible for locking and don't bother inner entities.
But if entity is just a "blue bird" with no owning aggregate than we
may need this locking...
Possible solutions:
- assume that there are no "free" entities, and by convention promote
them to be Aggregates
- different base classes (kind of smell)
Suggestions are welcome...
> And the second question. Why timestamped column for opt lock is used? There
> is a good explanation why we should avoid timestamp for opt lock:
> http://en.wikibooks.org/wiki/Java_Persistence/Basic_Attributes
yes, in general it will be a problem.
Thanks for a tip. Changed to Long
Sławek Sobótka
A few initial ideas:
* I would keep the BaseEntity as simple as possible (getId(), isNew()
methods). BaseEntity provides some kind of infrastructure, nothing
more.
* Entity database identification is also rather infrastructure than
domain (to force surrogate PKs). I prefer getEntityId() name than
getId(). I don't want to reserve "ID" name, it could mean a lot for
some domain.
* AbstractEntity is better name, BaseEntity instance does not make
sense (http://blog.joda.org/2011/08/implementations-of-interfaces-
prefixes.html).
* We could imagine subclass like VersionedEntity. But the class
hierarchy will explode.
* There is no need to BaseAggregateRoot class, aggregates are marked
within annotation.
* BaseAggregateRoot should be rather EntityWithEventSupport... class
(kind of smell). If your aggregate needs this support, use base class,
if not, don' use.
* If you need repository, the repository should operate only on
aggregate. For simple aggregates (e.g: dictionaries), you can put them
into the shared package as a simplification.
Sławek Sobótka
> methods). BaseEntity provides some kind of infrastructure, nothing
> more.
> * Entity database identification is also rather infrastructure than
> domain (to force surrogate PKs). I prefer getEntityId() name than
> getId(). I don't want to reserve "ID" name, it could mean a lot for
> some domain.
Changed.
> * AbstractEntity is better name, BaseEntity instance does not make
> sense (http://blog.joda.org/2011/08/implementations-of-interfaces-
> prefixes.html).
BaseEntity is abstract in sense of Java abstract keyword. It is
implemented this way because there is no sense of instancing this
class (as You mentioned)
but
there is nothing abstract in this class - so it's not abstract in
sense of design.
This class is just base (but not just "pull before the brackets", it
still respects Liskov SP).
Blog post says about context of their conventions - "different teams
in different companies" which *may* also mean: outsource to cheaper
companies where we can not assume that deeper consideration is even
possible - sad but life is life:|
> * We could imagine subclass like VersionedEntity. But the class
> hierarchy will explode.
> * There is no need to BaseAggregateRoot class, aggregates are marked
> within annotation.
> * BaseAggregateRoot should be rather EntityWithEventSupport... class
> (kind of smell). If your aggregate needs this support, use base class,
> if not, don' use.
In general what we can see is lack of expression power in Java.
Clear and elegant code could be achieved using traits/mixins.
> * If you need repository, the repository should operate only on
> aggregate. For simple aggregates (e.g: dictionaries), you can put them
> into the shared package as a simplification.
that we promote them to Aggregates than You are right.
Marcin Kuthan
> * AbstractEntity is better name, BaseEntity instance does not make
> sense (http://blog.joda.org/2011/08/implementations-of-interfaces-
> prefixes.html).
It depends on the personal sense of the sense;P
BaseEntity is abstract in sense of Java abstract keyword. It is
implemented this way because there is no sense of instancing this
class (as You mentioned)
but
there is nothing abstract in this class - so it's not abstract in
sense of design.
This class is just base (but not just "pull before the brackets", it
still respects Liskov SP).
Blog post says about context of their conventions - "different teams
in different companies" which *may* also mean: outsource to cheaper
companies where we can not assume that deeper consideration is even
possible - sad but life is life:|
> * We could imagine subclass like VersionedEntity. But the class
> hierarchy will explode.
yeap, definitely
> * There is no need to BaseAggregateRoot class, aggregates are marked
> within annotation.
BaseAggregateRoot is not just about "tagging". Thats the job for
annotation.
> * BaseAggregateRoot should be rather EntityWithEventSupport... class
> (kind of smell). If your aggregate needs this support, use base class,
> if not, don' use.
In future it can be something more than just event event support.
In general what we can see is lack of expression power in Java.
Clear and elegant code could be achieved using traits/mixins.
> * If you need repository, the repository should operate only on
> aggregate. For simple aggregates (e.g: dictionaries), you can put them
> into the shared package as a simplification.
Here we back to the question about "blue birds" entities. If we assume
that we promote them to Aggregates than You are right.
Sławomir Sobótka
>> > sense (http://blog.joda.org/2011/08/implementations-of-interfaces-
>> > prefixes.html).
>>
>> It depends on the personal sense of the sense;P
>>
>> BaseEntity is abstract in sense of Java abstract keyword. It is
>> implemented this way because there is no sense of instancing this
>> class (as You mentioned)
>> but
>> there is nothing abstract in this class - so it's not abstract in
>> sense of design.
>
> But you still marked the class as abstract. Why, if there is no abstract
> meaning? You could declare protected constructor instead.
> Personally I prefer Abstract prefix for all abstract classes, but it is
> personal sense of the sense, as you mentioned.
Abstract as a keyword is used as a "security" mechanism. Buy You are
right - protected constructor would do the same job.
For me personally this is rare situation when abstract (keyword) class
is actually not abstract (concept). In this case we have this strange
situation.
So honestly my intuition surrenders in this particular case:)
I also prefer in most cases adding Abstract prefix just to express
intention of the design. But adding it automatically (by convention)
to all abstract (keyword) classes looks the same as adding I to
interface names in some other popular language;P
> I would remove @version from BaseEntity at all. If there is an unused (for
> some scenario) method in BaseEntity it is cheap - no problem. But with
> @version the additional column in the DB is always needed, and JPA provider
> has to do some extra work. The entity with opt locking support is not a good
> candidate for base class for all entities. Too many side effects.
Ok, personally i lean to this idea but we will wait for others' opinions.
I'll post a thread about changes that need to be discussed.
>>
>> > * If you need repository, the repository should operate only on
>> > aggregate. For simple aggregates (e.g: dictionaries), you can put them
>> > into the shared package as a simplification.
>>
>> Here we back to the question about "blue birds" entities. If we assume
>> that we promote them to Aggregates than You are right.
>
> +1 for promotion "blue birds" to aggregate.
this will be associated with previous topic.