[hibernate-dev] Advice - cyclic event handling
Emmanuel Bernard
emmanuel at hibernate.org
Mon Sep 8 10:58:53 EDT 2014
Throwing off some ideas.
Have you thought about an entity A whose composed id is made of the id of
two different entities B and C.
A would enlist to B and C completion and would need to record when it
receives the first event and process everything when the second event
arrives?
A way around your problem could be to use index lookups instead of
iterators to process the watch list. That way you can set a specific
index to null when it is processed without affecting the subsequent
indexes nor raise a CME. That would be close to a ring buffer
implementation I suppose.
Emmanuel
On Tue 2014-09-02 13:41, Steve Ebersole wrote:
> As part of the metamodel work, one of things I am working on is redesigning
> the old notion of a "second pass" to be more efficient. For those not
> familiar, this represents a piece of processing that needs to be delayed
> until after another piece of processing is done. For example, processing a
> composite identifier metadata for an entity might depend on the identifier
> metadata for another entity being processed first.
>
> "second pass" was essentially one big bucket. In the new design I am
> trying to categorize or segment these things better, so we have different
> buckets (one for identifier metadata completion, one for attribute Type
> metadata completion, etc).
>
> Not to get too involved, but essentially a bucket is a List of "watchers"
> for specific "happenings" (I think of them as events, but am trying to
> avoid that terminology for now). E.g., take the "identifier metadata
> completion" bucket. As we complete the binding of the identifier metadata
> for an entity, we fire off a notification of that happening. The watchers
> can then react to that notification.
>
> The implementation of this is a List of watchers, as I said, which is
> iterated over for each notification. So here comes the trickiness. As
> each watcher is finished it needs to be removed from the list of watchers.
> And a watcher could in turn kick off a new notification (for it completing
> whatever it represents). So in the initial impl I ran into
> ConcurrentModificationException problems.
>
> I went ahead and made it work just to move forward. But I wanted to circle
> back and design this "right"; so I wanted to get others involved to see if
> anyone had thoughts or better ideas.
>
> Here is a simple example to use as a basis for discussion: consider the
> entity Customer and Order. Customer has a simple identifier, whereas Order
> has a composite identifier made up of (1) FK to Customer and (2) a order
> number. We need the identifier metadata for Customer to be completely
> bound before we can process the identifier metadata for Order. That is the
> crux of the problem to be solved. Its an ordering concern. If the
> metadata for the Customer entity is processed first, no big deal. But of
> course we can't really control that (putting the onus back on the user here
> is fugly). So we need to account for the case where metadata for the Order
> entity is processed first. This kind of timing thing is the reason for
> second passes and these new notifications. The idea in the new design is
> that we would register a watcher for Order which waits for the notification
> that Customer identifier metadata has been finished. As the identifier for
> each entity is completed, that process fires off a notification of that
> fact. So as the identifier metadata for Customer is finished, the process
> fires off a notification which makes its way back to the watcher for Order.
> Processing can now bind the identifier metadata for Order, and in turn
> fire off its notification.
>
> The trouble here, in the iteration impl, is that we are still iterating
> over the "identifier metadata completion" notification, so there is an
> active iterator over the list. When performing the Order-watcher
> processing, since it no longer needs to watch, we would ideally remove it.
> Initially I had simply exposed a deregistration method that removed the
> watcher from the list, but that ran into the problems with CME. What I do
> currently instead is to expose a method on the watcher contract for the
> watcher to say whether its work is done, and if so use the Iterator to
> remove it. That works, just not sure its the best option.
>
> Another consideration is the iteration over non-interested watchers. This
> may be a non-issue, not sure yet. Currently watchers simply register as
> being interested in identifier metadata completion notifications, not
> notifications for completion of identifier metadata for specific entity(s).
> So on the con side, the List would become a Map and we'd need a key
> object. On the plus side we'd avoid the iteration and CME problems
> altogether.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
More information about the hibernate-dev
mailing list