As explained in this article, Hibernate shifts the developer mindset from SQL to entity state transitions. A JPA entity may be in one of the following states:
- New/Transient: the entity is not associated with a persistence context, be it a newly created object the database doesn’t know anything about.
- Persistent: the entity is associated with a persistence context (residing in the 1st Level Cache) and there is a database row representing this entity.
- Detached: the entity was previously associated with a persistence context, but the persistence context was closed, or the entity was manually evicted.
- Removed: the entity was marked as removed and the persistence context will remove it from the database at flush time.
Moving an object from one state to another is done by calling the EntityManager methods such as:
Cascading allows propagating a given event from a parent to a child, also easing managing entities relationship management.
During the flush time, Hibernate will translate the changes recorded by the current Persistence Context into SQL queries.
Hibernate is a great ORM tool, and it eases development considerably, but it has a lot of gotchas you must be aware of if you want to use it properly.
On medium to large projects, it’s very common to have bidirectional parent-child associations, which allow us to navigate both ends of a given relationship.
When it comes to controlling the persist/merge part of the association, there are two options available. One would be to have the
@OneToMany end in charge of synchronizing the collection changes, but this is an inefficient approach.
The most common approach is when the @ManyToOne side controls the association and the @OneToMany end is using the “mappedBy” option.
I will discuss the latter approach since it’s the most common and the most efficient one, in terms of the executed queries number.
When working as a Scrum Master you have to constantly make sure the Scrum principles are followed, but there are also other aspects that requiring handling as well, and they are more subtle yet equally important for successfully managing developing teams.
I am talking about soft skills such as managing team conflicts, encouraging people, knowing how to challenge your team members. There are times when some of your guys behave inappropriately versus others, or their attitude/behavior is counter-productive and you have to step in and correct these problems with diplomacy and keen tact.
If you are not endowed with people handling skills, don’t despair, there is still hope. I don’t believe those telling these skills can’t ever be acquired and that you have to be born with them. With proper training, you can improve yourself sufficiently enough to be able to manage your team efficiently,
So, I will present you a great book that offers old solutions to new problems.
In the current application we are developing there was one use case where we wanted to synchronize message processing by message provider (customer generating those messaging). The flow looks something like this:
So messages may come randomly since there are more customer jobs running in parallel, but we want to ensure that messages belonging to the same customer are processed one after the other (analog to the Serializable Database isolation level) while allowing messages coming from different customers to be processed in parallel.
Spring Framework dependency injection is great, and almost every Java developer uses it nowadays. Using @Autowired to inject Java Beans is trivial, but we can also use this annotation for
java.util.Map as well. The former will inject a list of all Java Beans matching the List’s Generic type, while the latter will create a map of these beans mapped by their names.
How I’ve been taking advantage of this feature?
Since I was developing an application which has a framework module and a specific customer implementation module, there were cases where I needed to add a common logic in the framework module which would detect all Beans of a given type, even the ones defined in the specific module.