HHH-19602 - Adjust JdbcOperation to allow more-than-one statement

[sebersole]

HHH-19602 - Adjust JdbcOperation to allow more-than-one statement

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19602

[beikov]

LGTM

[sebersole]

In this last commit I have a generally working solution for simple cases, where I think the approach is one that is feasible for a first pass. It has some limitations currently -

• it makes some assumptions about the type of query wrt the things to lock
• does not yet work for locking entity tables with composite keys
• does not yet lock actual collection tables. in case of collections it will (currently) only lock the associations if requested (EXTENDED)

It also requires some changes to how JdbcSelectExecutor and especically JdbcValuesSourceProcessingState operate. We could mitigate this by instead putting the new LoadedValuesCollector reference on ExecutionContext (similar to Callback/AfterLoadAction), but that has always felt fugly.

Anyway, see FollowOnLockingParadigmTests#testFollowOnLockingFlow for the flow.

Anyway, what happens is that we issue the first selection (without locking) and load results as mormal. As part of that loading, LoadedValuesCollector is used to collect things that need to be locked. A post-action then is used to leverage the LoadedValuesCollector values and issue locking selects against each table, ultimately refreshing the state of the entity (and its loaded-state). So for example, from the test we have the primary operation, the select without locking -

    select
        t1_0.id,
        m1_0.team_fk,
        m1_0.id,
        m1_0.name,
        t1_0.name 
    from
        teams t1_0 
    left join
        persons m1_0 
            on t1_0.id=m1_0.team_fk 
    where
        t1_0.id=?

Which yields:

Loaded root entities:
    org.hibernate.orm.test.sql.exec.op.Team#1
Loaded non-root entities:
    org.hibernate.orm.test.sql.exec.op.Person#1
    org.hibernate.orm.test.sql.exec.op.Person#2
    org.hibernate.orm.test.sql.exec.op.Person#3
Loaded collections:
    org.hibernate.orm.test.sql.exec.op.Team.members#1

And then 2 additional queries -

    select
        tbl.id,
        tbl.name 
    from
        teams tbl 
    where
        tbl.id in (?) 
    for
        update

    select
        tbl.id,
        tbl.name 
    from
        persons tbl 
    where
        tbl.id in (?, ?, ?) 
    for
        update

As the results of these locking queries are processed, we update the "loaded state" and instance state for the entities.

[beikov]

Missing performPreActions() and performPostActions()?

[sebersole]

I'm just focusing on selections for now. And in fact, I'm folding all this into JdbcOperation itself locally. These DatabaseOPeration contracts are going away. (from the Zulip discussion)

But larger picture, implementing this generically for mutations is going to be a pain because of the difference in how mutations work between queries and model mutuations.

[sebersole]

A few notes:

1. I changed how locking is applied to native queries.
2. These last commits do add support for allowing post-actions to run after unsuccessful primary operations.
3. These last commits also include refactoring to org.hibernate.sql.exec which I mentioned on Zulip.

[sebersole]

One thing I do still want to look into is:

// todo (JdbcOperation) : Consider leveraging approach based on Dialect#useArrayForMultiValuedParameters

Also need to be sensitive to the number of keys to load and the number of supported parameters when using an in-list predicate

[sebersole]

Rebased and applied manually