Greetings!


i guess because batch inserts can not return many generated values
but for Stateless sessions they can be ignored, right?
So, may be that rule can be muted for StatlessSessions?

Bless you..

The reason why IDENTITY generated does not mix with JDBC batch inserts is because by the time flush comes, Hibernate already executed the inserts to know the entity identifier upon attaching the entity to the currently running Persistence Context.

However, because the StatelessSession does not have a Persistence Context, it has no way of delaying the inserts so that they can be batched during flushing, right?

Prior to joining the Hibernate team, I've been also involved in developing enterprise applications using Hibernate, especially Batch Processors. However, there was no instance where we ever needed to use the StatelessSession which has many inconveniences:

- does not implement a first-level cache
- nor interact with any second-level cache
- nor does it implement transactional write-behind or automatic dirty checking
- nor do operations cascade to associated instances
- Collections are ignored by a stateless session.
- bypass Hibernate's event model and interceptors (not very good for Envers either).
- vulnerable to data aliasing effects, due to the lack of a first-level cache.

So, we've been using the standard Session for all our batch processing. For more details about the best way of batching using JPA and Hibernate, check out this article.

Absolutely, it seems hibernate doing mistake extending that rule for StatelesSession too
StatelessSession inconveniences is not subject of my question, but thanks for that.

IDENTIY in my solution potentially can provide better performance
Because SequenceStyleGenerator has extra queries to sequences

In case of Oracle RDBMS
Identity is just wrapper under Sequence

That's the case for PostgreSQL as well. However, it's much more efficient for Hibernate to use a SEQUENCE than IDENTITY.

I got it, thank you very much!