[hibernate-dev] HHH-10478 : OperationContext

[Gail Badner]

Hi Steve,

I can start integrating this code into your wip/6.0 branch. Are there any
fundamental changes you would like to see before I integrate, or should I
integrate as is?

Thanks,
Gail

On Fri, Apr 1, 2016 at 12:14 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I do like the proposal.  Awesome job on the gist.  I'll look over the code
> over the next few days.
>
> On Thu, Mar 31, 2016 at 3:05 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> Replying for consideration for 6.0.
>>
>> On Mon, Feb 8, 2016 at 6:12 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> This is going to have to wait post-5.1 as I mentioned earlier if this
>>> was not ready prior to last week.
>>>
>>> I have just too much on my plate to look at this over 2 days.
>>>
>>> On Mon, Feb 8, 2016 at 12:29 AM Gail Badner <gbadner at redhat.com> wrote:
>>>
>>>> The POC [1] assumes that we only need a single OperationContext for each
>>>> type of operation. OperationContextManager has a Map of
>>>> OperationContext by
>>>> OperationContextType. Each OperationContext object is lazily created on
>>>> the
>>>> first occurence of the corresponding type of operation.
>>>>
>>>> Currently, when an operation is initiated (e.g., by Session.merge(
>>>> entity
>>>> )), OperationContextManager [2] does the following:
>>>> - calls ManageableOperationContext#beforeOperation, which puts the
>>>> OperationContext "in progress";
>>>> - executes the operation, which performs cascades according to mappings;
>>>> - calls ManageableOperationContext#afterOperation, which puts the
>>>> OperationContext in an invalid state that is "not in progress".
>>>>
>>>> When an operation cascades to other entities, the same OperationContext
>>>> is
>>>> used.
>>>>
>>>> Obviously, OperationContextManager needs to know if an operation is
>>>> "top-level" (meaning that the operation is on the original entity, and
>>>> not
>>>> cascaded). In the POC, if the relevant OperationContext is not in
>>>> progress
>>>> at the time that an opeation is initiated, then OperationContextManager
>>>> assumes that the operation is top-level. If the OperationContext is "in
>>>> progress", then OperationContextManager assumes that this is a cascaded
>>>> operation.
>>>>
>>>> I am not sure this is always correct. Can anyone think of a case where
>>>> this
>>>> could break down?
>>>>
>>>> In the POC, the following EventSource methods that contain an argument
>>>> for
>>>> the operation cache has been deprecated and is no longer used because
>>>> the
>>>> contents of that argument has been moved into an OperationContext:
>>>>
>>>> public void merge(String entityName, Object object, Map copiedAlready)
>>>> public void persist(String entityName, Object object, Map
>>>> createdAlready)
>>>> public void persistOnFlush(String entityName, Object object, Map
>>>> copiedAlready)
>>>> public void refresh(String entityName, Object object, Map
>>>> refreshedAlready)
>>>> public void delete(String entityName, Object child, boolean
>>>> isCascadeDeleteEnabled, Set transientEntities)
>>>>
>>>> Before the POC, it was the above methods that indicated that it was not
>>>> top-level. If it turns out that having a single OperationContext is not
>>>> valid, then there needs to be some other way to determine if the
>>>> operation
>>>> was top-level.
>>>>
>>>> I had originally planned to use PersistenceContext#getCascadeLevel ==
>>>> 0 to
>>>> indicate an operation was at the top-level, but I found that won't work
>>>> for
>>>> some operations. For example, the cascade level for a top-level delete
>>>> can
>>>> be > 1 when deleting orphans due to merge or save-or-update operations.
>>>> Another example is that cascade level is not 0 on top-level
>>>> save-or-update
>>>> while flushing.
>>>>
>>>> I have some ideas to work around this, but I didn't want to get too far
>>>> down that path if it wasn't an issue.
>>>>
>>>> Thanks,
>>>> Gail
>>>>
>>>> [1]
>>>> https://github.com/gbadner/hibernate-core/blob/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/
>>>> main/java/org/hibernate/engine/operationContext/internal/
>>>> OperationContextManager.java
>>>> [2]
>>>> https://github.com/gbadner/hibernate-core/blob/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8/hibernate-core/src/
>>>> main/java/org/hibernate/engine/operationContext/internal/
>>>> OperationContextManager.java#L132
>>>>
>>>>
>>>> On Fri, Feb 5, 2016 at 8:17 PM, Gail Badner <gbadner at redhat.com> wrote:
>>>>
>>>> > I've created a gist with an overview of the design:
>>>> > https://gist.github.com/gbadner/f0e635e8fba7b84af233 . I will add a
>>>> new
>>>> > section tomorrow about possible shortcomings.
>>>> >
>>>> > Here is my POC:
>>>> > https://github.com/hibernate/hibernate-orm/compare/master..
>>>> .gbadner:HHH-10478-OperationContext
>>>> > . Although no tests fail, the approach may be too simple to model
>>>> what is
>>>> > necessary.
>>>> >
>>>> > At this point the POC is squashed down to 1 commit:
>>>> > https://github.com/hibernate/hibernate-orm/commit/
>>>> 3d0e2378cb998788b3205afb1e15c443c5ba77e8
>>>> >
>>>> > Have a look and feel free to comment.
>>>> >
>>>> > Thanks,
>>>> > Gail
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>